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Abstract 

This thesis investigates a particular approach, called state-transition specification, 
to the problem of describing the behavior of modules in a distributed or concurrent 
computer system. A state-transition specification consists of: (1) a state machine, 
which incorporates the safety or invariance properties of the module, and (2) validity 
conditions on the computations of the machine, which capture the desired liveness or 
eventuality properties. The tiieory and techniques of state-transition specification are 
developed from first principles to a point at which it is possible to write example 
specifications, to check the specifications for consistency, and to perform correctness 
proofs using th« specification* The utility of the techniques is demonstrated through 
examples. 

Major contributions of the thesis include: (1) the definition of a semantic model 
that incorporates hierarchy of abstraction and modular decomposition as fundamental 
notions; (2) specification and proof techniques that smoothly handle both safety and 
liveness properties; (3) techniques that use Wveness properties stated in 
rely-/ guarantee-condition form to obtain simple proofs of correctness; (4) an interesting 
and useful notion of consistency tor specifications involving liveness properties. 
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1. Introduction 

The purpose of this thesis is to investigate a particular approach, called 
state-transition specification, to the problem of describing the behavior of modules in a 
concurrent or distributed computer system. In the state-transition approach, the 
desired behavior is described in terms of a kind of state machine whose computations 
generate records of event occurrences, called observations. A state-transition 
specification consists of two parts: (1) the definition of the state machine, which 
incorporates the "safety" or invariance properties of the module, and (2) the definition 
of some validity conditions on the computations of the machine, whose purpose is to 
capture the desired module "liveness" or eventuality properties. A state-transition 
specification defines a set of "acceptable" observations, namely the observations 
produced by valid computations of the state machine. A module behavior satisfies such 
a specification if the module behavior contains only acceptable observations. 

The idea of describing module behavior with the help of state machines is not new, 
having already been proposed in various forms by other authors, [e.g. Parnas72, 
Yonezawa77, Lamport83]. However, previous work seems to be concerned primarily 
with how to write module specifications, and how to use proof rules to prove the 
correctness of implementations. The important issues pf what constitutes the meaning 
of a specification, and what it means for an implementation to be correct, have not 
received satisfactory treatment. As a result, it is impossible to answer important 
questions such as: "What rules are sound for proving the correctness of an 
implementation," and "When is a specification consistent?" 

This thesis improves upon previous work by systematically developing the theory 
and techniques of specification from "first principles" to a point at which it is possible to 
write example specifications, to prove implementations correct, and to check 
specifications for consistency. The theory incorporates an underlying semantic model 
within which one can formulate language- independent definitions of the notions of 
"implementation" and "correctness." The meaning of state-transition specifications is 
defined in terms of the model, and all proof techniques are shown to be sound with 
respect to the model. 
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The major contributions of this thesis are: 

(1) The definition of a semantic model that incorporates hierarchy of 
abstraction and modular decomposition as fundamental notions. 

(2) Specification and proof techniques that smoothly handle both safety and 
liveness properties. 

(3) Techniques that use liveness properties stated in rely-/guarantee-condition 
form to obtain simple proofs of correctness. 

(4) An interesting and useful notion of consistency for specifications involving 
liveness properties. 

(5) Illustration of the utility of the ideas developed through specifications, 
implementations, and correctness proofs for three examples: 

(a) a synchronizer module, which is implemented by a ring-structured 
network of synchronizer component modules, 

(b) a resource management module, which is implemented by a 
tree-structured network of local resource manager modules, 

(c) a message transmission module, which is implemented by unreliable 
transmission line modules, a send protocol module, and a receive protocol module, 
which together obey the alternating bit protocol. 

1.1 Scope of the Thesis 

A specification is a piece of text whose purpose is to describe the desired 
operation of a module in a computer system. Specifications form an integral part of a 
"top-down" design method in which design proceeds by the successive decomposition 
of a module to be implemented into a collection of interacting component modules 
[Liskov79, Wirth71]. The purpose of specifications in such an approach is to serve as a 
contract between the user and the implementer of a module. This helps to limit 
complexity by permitting a system to be decomposed into modules of reasonable size, 
such that each module depends only upon the specifications, and not the 
implementations, of the modules with which it interacts. 

To permit the possibility of rigorous reasoning about specifications, a specification 
language should be given a formal semantics in terms of an underlying mathematical 
semantic domain. In this thesis, we use the term behavior to refer to the elements of a 
semantic domain, since the purpose of these elements is to serve as a mathematical 
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model of the behavior of a portion of a real-world computer system. The semantics of a 
specification language describe how each specification denotes a set of behaviors that 
satisfy the specification. If the semantics of a programming language are defined so 
that each important program fragment denotes a behavior, then it is possible to derive 
syntactic rules for proving that (the denotations of) program fragments satisfy (the 
denotations of) specifications. The purpose of this thesis is not to propose particular 
formal specification or programming languages, but rather to investigate a collection of 
language-independent semantic concepts upon which particular specification and 
programming languages might be based. We therefore assume that specification and 
programming languages can have their meanings defined in terms of behaviors, and do 
not concern ourselves with the precise method by which this is accomplished. 

In this thesis, we are concerned with concurrent or distributed systems. By this we 
mean systems that are most naturally viewed as a collection of independent, 
communicating modules, such that effects of concurrent operation of the various 
modules form a significant part of the description of system behavior. This thesis is 
primarily concerned with the conriirr«ncy aspect of distributed computing; while the 
model and techniques do not rule out the possibility of treating other aspects such as 
node crashes and network failures, no special structure to deal with these problems is 
included. The techniques of this thesis have been developed primarily with the idea that 
they would be applied to the problem of describing and reasoning about distributed 
algorithms. The examples presented are of this kind. 

1 .2 An Example 

In this section, an example specification problem will be used to introduce 
informally the fundamental ideas about specification on which this thesis is based. 

1.2.1 The Synchronizer Module 

Consider the following scenario: A number of processes in a computer system 
require the use of a single resource to accomplish their respective tasks; however, 
because of limitations inherent in the resource, at most one process can be allowed to 
access the resource at any instant of time. To enforce this restriction, a synchronizer 
module is introduced, and the processes, which we will refer to as the user processes, 
are required to obtain permission from the synchronizer module before accessing the 



9 



resource. It is the job of the synchronizer module to produce correct synchronization of 
the user processes' accesses to the resource. Our problem is to describe precisely the 
synchronizer module behaviors that are "acceptable" in the sense that they always 
produce "correct synchronization." This precise description is the specification of the 
synchronizer module. 

When a user process desires to access the resource, it issues a try request to the 
synchronizer module. The user process is then supposed to wait until it receives a run 
response from the synchronizer module. When the user process is finished using the 
resource, it issues a rest response to the synchronizer module. We can capture these 
decisions in diagrammatic form as shown in Figure 1 , in which the synchonizer module 
is depicted as a circle, and the possible requests and responses are drawn as arcs 
incident on and exiting from the circle, respectively. We assume that there are a total of 
N user processes accessing the synchronizer module, and have used a subscripted 
process number to distinguish the requests and responses corresponding to different 
processes. 



Fig. 1. The Synchronizer Module 



run , 




run 



N 
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The set of all possible requests and responses for the synchronizer module can be 
thought of as an "alphabet" or "syntax" for describing the interaction of the 
synchronizer module with its environment. We call this set the interface of the 
synchronizer module, and refer to its elements as events. By observing the 
synchronizer module during an execution, we can obtain a record of the events that 
occurred during the execution. We call th|s record of event occurrences an 
observation, and assume that it takes the form of a finite or infinite sequence of events. 

By fixing the interface of the synchronizer module to be a particular set of events, 
we determine a universe of possible observations. We next consider how to describe 
which observations in this universe are "acceptable." We must include in our 
description the idea that at most one user process at a time may access the resource. 
Also, we wish to require that the synchronizer module be fair in the sense that every try 
request by a user process is eventually answered by a run response, if it is possible to 
do so without violating the mutual exclusion property. 

A natural way of describing which observations are acceptable is through the use 
of conceptual states. With this technique, we imagine that at any instant of time the 
synchronizer is in one of a number of possible internal states. These states may or may 
not have anything to do with the actual internal state of the synchronizer module; they 
are merely a tool for describing its observable behavior. After defining the set of initial 
states, we then describe for each event the preconditions required for that event to 
occur, and how the conceptual state of the synchronizer changes as a result of the 
occurrence of that event. 

The conceptual state of the synchronizer module at any instant of time is a vector 
that tells for each user process what the synchronizer module thinks that user is 
currently doing with respect to the resource, based on the requests and responses that 
have occurred so far. The possibilities are that the user is either trying to obtain 
permission to access the resource (trying), is actively using the resource (running), is 
done using the resource (resting), or has failed to correctly follow the protocol (error). 



1 . The formal definition of observation used in this thesis is slightly more complicated 
than a finite or infinite sequences of events (see Chapter 2). This is done for technical 
reasons that are unimportant for the present, informal discussion. 
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Initially, the synchronizer module believes that each user process is resting. The state 
changes and preconditions are as follows: a try event for a process causes the state of 
that process to change to "trying" if it was previously resting, and to "error" otherwise; 
a run event for a process can occur only if that process is trying and no processes are 
currently running, and causes the state for that process to change to "running;" a rest 
event for a process causes the state of that process to change to "resting" if it was 
previously running, otherwise to "error." 

A particular observation for the synchronizer module satisfies the description of 
the previous paragraph if to each finite prefix of the observation we can assign a 
conceptual state in such a way that each state change satisfies the conditions 
enumerated in the previous paragraph. For example, assuming there are only two user 
processes, the observation 

try , try 2 run, rest, run 2 rest 2 
satisfies the conditions above since we can assign internal states as follows: 

<resting, resting> try, <trying, resting> try 2 <trying, trying> run, <running, trying> 
rest f <restinn. trying> mn 2 <resfing, running> rest x 
<resting, restingX 
However, the observation 

try, try 2 run, run 2 rest, rest 2 
does not represent a correct functioning of the synchronizer module since 

<resting, resting> try, <trying, resting> try 2 <trying, trying> run, <running, trying> 
run 2 <running, running> rest, <resting, running> resf 2 
<resting, resting>, 
which is the only assignment of states that satisfies the state change requirements, has 
the property that the precondition for the run 2 event is not satisfied by the state 
<running, trying>. We will use the term "history" to refer to an observation that has 
been annotated with states. 

The state-transition description above tells us a significant amount about what are 
the correct observations of the synchronizer module, but it does not say everything that 
should be said. In particular, the requirement that every request by a user process 
should eventually be satisfied, if possible, is not captured by the state-transition 
description. Informally, the reason is that a state-transition description captures only 
properties of histories that are "local" in the sense that they involve only adjacent 
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states, whereas the fairness property we would like is a "global" property that involves 
possibly widely separated portions of the history. If the conceptual state technique is to 
work, we must find some way to state global properties in a form compatible with the 
statement of the local properties. In Chapter 4 it will be shown how global properties 
can be expressed in the language of temporal logic. 

A specification of the synchronizer module via the conceptual state approach 
therefore consists of a state-transition description of the local properties that must be 
satisfied by acceptable observations, plus a description of additional global properties 
satisfied by such observations. A particular synchronizer module behavior is said to 
satisfy the synchronizer module specification if it contains only acceptable 
observations. 

1.2.2 Implementation, Abstraction, and Composition 

Now let us consider how the synchronizer module might be implemented. A 
possible organization is shown in Figure 2. In Figure 2, the synchronizer module is 
shown to be composed of a number of "synchronizer component" modules connected 
in a ring-like fashion. Each synchronizer component module interacts with exactly one 
user process and with its neighboring synchronizer component modules. The 
implementation operates as follows: There is a single conceptual token that circulates 
around the ring in the clockwise direction. A synchronizer component module must 
possess the token whenever it grants its associated user permission to access the 
resource. In addition to the try, run, and rest events with which communication with the 
user is accomplished, a synchronizer component module may pass the token to its 
clockwise neighbor with a tokenjovt event, may receive the token from its 
counterclockwise neighbor with a tokenjn event, may request the token from its 
counterclockwise neighbor with a requestjout event, and may accept a request from its 
clockwise neighbor with a request Jn event. 

We resolve the implementation relationship between the synchronizer component 
modules and the synchronizer module into two separate operations on systems: a 
composition operation, which takes a number of component modules and combines 
them into a larger system, and an abstraction operation, which takes the larger system 
and throws away internal details that are not of interest in the more abstract view. In the 
synchronizer example the composition operation takes a collection of synchronizer 
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Fig. 2. Implementation of the Synchronizer Module 




Synchronizer 
Module 



component modules and connects them Into a ring network, and the abstraction 
operation throws away the details of the Internal communication between the 
component modules, saving only the events that make up the interface with the user 
processes. 



-14- 



1 .2.3 Correctness of an Implementation 

Suppose we are given a specification for the synchronizer module, and 
specifications for each of the synchronizer component modules. Each specification 
determines a set of behaviors that satisfy it. The implementation is "correct" with 
respect to these specifications if, no matter what behaviors we "plug in" for the 
synchronizer component modules, as long as each component behavior satisfies its 
specification, then the resulting synchronizer module behavior, constructed from the 
components via the operations of composition and abstraction, satisfies the 
synchronizer module specification. 

1.2.4 Summary 

The ideas presented in this section can be summarized as follows: 

(1 ) Every module in a system has a well defined interface, which is the syntax 
with which it interacts with other modules in the system. 

(2) An interface defines a universe of observations, which are records of 
operation that might be produced by a module with that interface. These observations 
constitute the possible "functionings" of the module. The set of all observations that 
can be produced by a particular module instance serves as the behavior of that module 
instance. 

(3) A module can be specified by describing a set of "acceptable" 
observations. A module behavior "satisfies" such a specification if it contains only 
acceptable observations. 

(4) An implementation of an abstract module in terms of a collection of 
component modules consists of a composition operation for combining component 
module behaviors to form a "composite" behavior, and an abstraction operation for 
deleting information from the composite behavior to obtain a behavior of the abstract 
module. 

(5) An implementation is correct with respect to given specifications if, 
whenever we apply the composition operation of the implementation to a collection of 
behaviors that satisfy the component module specifications, and then apply the 
abstraction operation of the implementation to the resulting composite behavior, we 
obtain a behavior that satisfies the abstract module specification. 
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1.3 Outline of the Thesis 

This thesis is an attempt to elaborate and make more precise the ideas illustrated 
informally in the previous section. In particular, an attempt will be made to answer the 

questions: 

(1) What is an appropriate mathematical framework that adequately captures 
the notions of interface, observation, composition, abstraction, implementation, 
specification, and correctness discussed above? (Chapter 2) 

(2) How can we translate, in a natural and systematic way, an intuitive 
understanding of the function to be performed by a module into a precise specification? 
(State-Transition Specifications, Chapter 3) 

(3) Once we have obtained such a specification, how can we be sure that it 
says something meaningful? (Consistency of specifications, Chapter 5) 

(4) How can we show, in a systematic way, that a particular implementation of 
an abstract module by a collection of component modules is correct with respect to 
given specifications? (Correctness Proofs, Chapters 3, 4, Appendix II) 

(5) What general principles can we learn about how to organize specifications 
and proofs of correctness? (Rely/Guarantee-Conditions, Chapters 3, 4, Appendix II) 

(6) How might the specification and proof techniques developed in this thesis 
be formalized to permit the use of mechanical aids? (Event/State Algebras, Appendix I). 

This thesis is organized as follows: Chapter 2 introduces formal definitions of the 
notions of interface, observation, abstraction, composition, implementation, and 
correctness. Some of the modeling choices embodied in these definitions are 
discussed. 

In Chapter 3, the basic definitions of Chapter 2 are used to define formally the 
notion of a state-transition specification. The main result of Chapter 3 is the 
Correctness Theorem (Theorem 3.9), which shows how the structure of state-transition 
specifications can be exploited to obtain a systematic method for performing 
correctness proofs. Secondary results of Chapter 3 (Lemma 3.1 1 , Lemma 3.1 2) suggest 
how the proof method embodied in the Correctness Theorem can be further 
systematized if module liveness specifications are expressed in terms of 
rely-/guarantee-conditions. 
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Chapter 4 applies the theory of Chapters 2 and 3 to the synchronizer example. 
The complete specifications of the synchronizer and synchronizer component modules 
are presented, and the synchronizer implementation is proved correct with respect to 
these specifications. The language of temporal logic is used as a notation for 
expressing liveness properties. 

Chapter 5 is concerned with finding an appropriate notion of consistency of 
specifications that include nontrivial liveness properties. Intuitively, a specification 
ought to be consistent if and only if it is satisfiable by some behavior. However, if by the 
term "behavior" we mean "arbitrary set of observations," then we obtain a notion of 
consistency that is much too liberal. To obtain stronger notions of consistency, we must 
restrict our attention to "realizable" or "computable" behaviors. Chapter 5 introduces a 
particular class of computable behaviors, the "l/O-behaviors," that is based on an 
underlying model of asynchronous concurrent computation called "l/O-systems." The 
corresponding notion of "l/O-consistency" is found to be useful for distinguishing 
between "obviously realizable" and "obviously unrealizable" liveness specifications. 
Chapter 5 develops n technique for proving state-transition specifications to be 
l/O-consistent and applies this technique to examples. 

In Chapter 6 a kind of completeness result is proved (the Completeness Theorem, 
Theorem 6.4), which gives sufficient conditions under which a correct implementation 
has a proof by the Correctness Theorem. The statement and proof of Theorem 6.4 uses 
in a crucial way the existence of a "specification domain," which is a class of behaviors, 
like the l/O-behaviors, with certain closure properties. 

Finally, Chapter 7 summarizes what has been accomplished and suggests avenues 
for future investigation. 

Additional important material is contained in Appendices I, II, and III. Appendix I 
provides a formal semantics for the temporal logic language used informally in Chapters 
4-6, and shows the correctness and consistency proof techniques developed in the 
thesis can be formalized within this language. Appendix II considers two additional 
examples: a distributed resource management system, and a reliable message 
transmission system based on the alternating bit protocol. Both of these systems are 
specified and proved correct using the techniques developed in the main body of the 
thesis. Appendix III is an index of definitions. 
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1.4 Related Work 

The rather large body of work related to this thesis can be divided roughly into the 
following categories: 

(1) Specification of sequential programs/abstract data types. 

(2) Models of distributed /concurrent computation. 

(3) Temporal logic specification techniques. 

(4) Specification of communication protocols. 

(5) Other distributed/concurrent system specification techniques. 

Each of these categories will be discussed below. Further discussion is included at 
appropriate points in this thesis. 

1 .4.1 Specification of Sequential Programs/Abstract Data Types 

Work in the area of specification of sequential programs can be classified into two 
categories: that concerned with the specification of the function to be performed by a 
program or program fragment, and that concerned with the specification of the data 
types manipulated by a program. 

Sequential Program Function Specification 

Specification of the function to be performed by a program or program fragment is 
a problem that must be addressed by any work on program correctness. In the 
sequential case, the semantics of a programming language assigns to each program 
fragment (statement, procedure, etc.) some mathematical object (denotation) 
representing the effect of executing that fragment. Typically, (see, e.g. [Jones81]) this 
denotation takes the form of a partial function or a binary relation on program states. A 
specification for a program fragment consists of some properties that must be satisfied 
by the denotation of that fragment. 

Often function specifications are expressed in the form of Floyd/Hoare partial 
correctness assertions (PCA's) [Floyd67, Hoare69], consisting of a precondition and a 
postcondition, which are predicates on states. A program fragment satisfies a PCA if, 
whenever execution of the fragment is begun in a state satisfying the precondition, then 
execution will terminate only in a state satisfying the postcondition. Thus, if binary 
relations are used as denotations of fragments, a PCA is satisfied by any relation R such 
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that if <q, r> € R and q satisfies the precondition of the PCA, then r satisfies the 
postcondition. 

Besides being convenient for specifying the function that must be satisfied by a 
program fragment, partial correctness assertions can be used to construct a formal 
deductive system for reasoning about the behavior of program fragments. For a good 
overview of these "Hoare logics" of programs, see [Apt81]. 

The partial correctness assertion technique has been generalized with some 
success to systems of concurrent processes [e.g. Owicki76]. However these 
techniques suffer from a lack of modularity in the sense that there is no notion of the 
behavior of a single process in isolation. Thus it is possible to specify the function of a 
complete parallel program, but not the behavior of its constituent processes. Although 
a logic of partial correctness assertions is used to prove that the behavior of a program 
satisfies its specification, the truth of PCA's associated with one process cannot be 
determined, except within the context of the PCA's for all other processes. 

Partial correctness assertions are capabln of fixnressing only safety properties of 
the form: "Whenever control is at point P, then relation R holds on the program 
variables. In general, one is interested in liveness specifications as well. For sequential 
programs, often the only liveness specifications of interest are statements that the 
program is guaranteed to terminate under certain conditions. Liveness properties of 
this simple form can be handled by incorporating termination into PCA's, as in Dijkstra's 
calculus of "weakest preconditions" [Dijkstra76], or by techniques completely outside 
of PCA's, such as Floyd's well-founded set technique [Floyd67]. For distributed or 
concurrent programs, it is almost always the case that more general liveness properties 
than simple termination are of interest, and these require alternative techniques. 

Data Type Specification 

The problem of describing the data objects manipulated by a program, especially 
the user-defined data objects, is usually referred to as "specification of abstract data 
types." There are actually two quite different problems that are addressed in the 
literature on abstract data type specification: the specification of immutable abstract 
data types, whose objects do not change their state during execution, and the 
specification of mutable abstract data types, whose objects have changeable state. 
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Specification of immutable abstract data types is the problem of describing and 
reasoning about static collections of values, functions, and relations. Usually a 
collection of interdependent immutable abstract data types is identified with the 
mathematical notion of a heterogeneous algebra, and algebras are described either 
axiomatically, as in [Guttag78, Goguen78, Kapur80], or via set-theoretic constructions, 
as in [Abrial80]. Specification of mutable abstract data types, on the other hand, can be 
thought of as the problem of describing and reasoning about the dynamic behavior of a 
collection of objects that can be manipulated using a limited set of procedures 
[Guttag80, Wing83]. Berzins [Berzins79] models a mutable abstract data type as a kind 
of state machine, which describes how the states of the mutable data objects evolve as 
a result of the invocation of the procedures. 

The problem of specifying immutable abstract data types is not addressed by this 
thesis. In fact, the specification and proof techniques presented in this thesis assume 
as a prerequisite the ability to describe heterogeneous algebras and to perform 
reasoning about such algebras once they have been described. On the other hand, the 
problem of specifying mutable abstract data types can be viewed as a sped?.! case of 
the general problem of module specification considered in this thesis, by thinking of a 
mutable abstract data type in terms of a "type manager" module, which encapsulates 
the objects of the data type and which performs manipulations on these objects in 
response to requests by the environment. Viewed in this way, the purpose of a mutable 
abstract data type specification is to describe the correct "observations" for the type 
manager module. The notion of observation appropriate here is that of a history of 
"events," where each event records either a request for the type manager to perform 
some manipulation on the objects, or a reply indicating the results of some previously 
requested manipulation. 

1 .4.2 Models of Concurrent Computation 

Quite a number of models have been proposed for investigating concurrent and 
distributed computer programs [Brock83, Hoare81b, Hoare81a, Greif75, Hewitt77, 
Kahn74, Ke!ler76, Lynch81, Pratt82, Rounds81]. In this thesis as well, specific 
assumptions are made about how to model the behavior of such systems. It is 
necessary to make these assumptions to reach a point at which concrete example 
specifications can be written and correctness proofs performed. However, a conscious 
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effort has been made to assume no more structure than is necessary for the results of 
this thesis. An attempt has been made to identify a few fundamental concepts that are 
required of any model, if it is to serve as a semantic foundation for the theory of 
specification developed here. 

The fundamental concepts identified in this thesis are the notions of interface, 
observation, behavior, abstraction, and composition. These concepts, which have 
already been informally discussed, are given formal definitions in Chapter 2. In this 
section, we will briefly review the features of a number of extant models of concurrency 
and attempt to identify the notions of event, interface, observation, behavior, 
abstraction, and composition used here with corresponding notions in each of the 
models. We will also be interested in whether each model is suitable as a semantic 
basis for a specification language -• in particular, whether the model can model is useful 
for specifications involving liveness properties. 

Kahn-MacQueen Processes 

A ruliiei eieyant model of concurrent compulation is the stream processing model 
of Kahn [Kahn74] and Kahn and MacOueen [Kahn77]. In this model, a process 
communicates with its environment through a collection of named channels. A process 
uses each channel either as an input channel ot an output channel, but never as both. 
During execution, a process can read input values from input channels and emit output 
values on output channels. We can imagine observing a process throughout an entire 
execution and recording the sequence of values transmitted on each channel. Such a 
sequence of values, which can be either finite or infinite, is called a stream. A process is 
modeled by a continuous function from tuples of input streams to tuples of output 
streams. The notion of continuity used here is derived from the fact that streams under 
the prefix ordering form a partially ordered set which is complete under limits of 
increasing chains. Processes are deterministic in the sense that to each input tuple /, 
there is precisely one output tuple O that can be produced by a particular process, 
when that process is supplied with input /. This is a consequence of the fact that 
processes are modeled by functions. 

In the stream processing model, the sets of input and output channels used by a 
process serve as the interface of that process. The role of an observation of a process 
is played by a pair </, 0>, where / is a tuple of streams corresponding to the input 
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channels, and O is a tuple of streams corresponding to the output channels. The usual 
identification of a function with its graph permits us to view a process behavior / as the 
set of all observations of the form </, /(/)>. 

A process network describes how to compose a collection of processes to form a 
composite system. Formally, a process network defines a kind of fixed point 
construction that maps a collection of component process behaviors to a behavior for 
the composite network. These fixed point constructions comprise the composition 
operations. The composition operations used by Kahn and MacQueen include features 
of both composition and abstraction as defined here, in the sense that once two 
processes have been connected by a communication channel, the stream of values 
transmitted over that channel is no longer of interest, and is ignored. 

The Kahn/MacQueen model is unsuitable for the purposes of this thesis because 
it is incapable of representing processes with nondeterministic behavior. 

Nondeterministic Process Nets 

There have been several attempts to generalize the stream processing model of 
Kahn and MacQueen to incorporate nondeterminism. One such attempt is reported by 
Brock in [Brock83] (superseding the earlier version [Brock8l] by Brock and 
Ackermann), where references to other attempts are given. In [Brock83], it is shown 
that the straightforward attempt to generalize the model of Kahn and MacQueen by 
permitting process behaviors to be relations, rather than functions, is doomed to failure. 
Intuitively, the reason is that the behavior of nondeterministic processes depends, in 
general, on the relative orders in which inputs are received and outputs produced. In 
essence, Brock's approach is to replace the </, 0> observations used by Kahn and 
MacQueen by scenarios. Scenarios include, in addition to the streams of values 
transmitted on each of the channels, a partial ordering that records some of the 
information concerning the temporal order in which values were transmitted. The 
behavior of a process is defined to be the set of all scenarios that the process can 
produce in its various executions. Brock shows how composition operations on 
scenario sets can be defined, in analogy to the operations on continuous functions 
defined by Kahn and MacQueen. 
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Pratt's [Pratt82] "repackages" Brock's model into a general framework for 
modeling processes and their composition, in which the behavior of a process is 
represented by the set of all traces (partially ordered multisets of events) it is capable of 
producing. As in the models of Kahn/MacOueen and Brock, the interface of a process 
can be identified with the set of all events in which the process can participate. The 
notion of trace plays the role of an observation. The notion of the restriction of a trace 
to a subset of its events is used to define composition of process behaviors. Restriction 
mappings on traces play essentially the same role in Pratt's model as decomposition 
maps play in the model of this thesis. 

The models of Brock and Pratt admit the possibility of infinite scenarios or traces, 
and therefore do not a priori rule out the possibility of modeling processes that satisfy 
nontrivial liveness properties. However, this possibility is not addressed by either Brock 
or Pratt. Since we are interested in modeling processes with liveness properties, the 
models of Brock and Pratt are not suitable in their present state of development. 

Communicating Sequential Processes 

An important class of models of concurrency [Francez79, Hoare81a, Hoare81b, 
Rounds81] has been developed through attempts to give a formal semantics to the 
language of "Communicating Sequential Processes" (CSP) defined in [Hoare78]. In 
each of these models, the behavior of a process describes the traces (finite sequences 
of communication events) in which the process is willing to participate as it executes. 
The set of all events in which a process can ever participate plays the role of the 
interface of that process. The notion of a trace plays the role of an observation. 
Although the particular notion of process behavior is different for different models, each 
of the models of CSP contains a collection of algebraic operations on process 
behaviors, which are used to define the meaning of the various constructs of CSP. In 
particular, each model has some sort of "restriction" or "hiding" operations, which 
cause events to be deleted from a process behavior, and some sort of "relabeling" 
operations, which allow events of a process to be renamed. These operations are used 
for essentially the same purpose as the abstraction operations used in this thesis. Each 
model also has one or more "composition" operations (composition by intersection, 
composition by interleaving, or a mixture of the two) corresponding to the composition 
operators of this chapter, whose effect is to combine process behaviors in various ways. 
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The important considerations for models of CSP derive from a feature peculiar to 
that language. A CSP process can refuse to communicate with its environment. If a 
CSP process refuses to perform any of the communications offered by its environment, 
then deadlock is the result. The different definitions of process behaviors in the various 
models of CSP arise from attempting to deal with (or to ignore) the subtleties of refusals 
and nondeterminism. 

In [Hoare81b], a process behavior is a prefix-closed set of traces, which can be 
viewed equivalents as a behavior of the kind defined in this thesis. There are 
operations in [Hoare81bJ for deleting and renaming the events of a process. These 
operations are examples of the abstraction operators used in this thesis. Process 
behaviors are composed by the parallel composition operator ||, which is defined as 
follows: If A is the behavior of a process with interface E and B is the behavior of a 
process with interface F, then A || 8 is the set of all traces u formed from events in E U F 
such that the restriction of u to E is in A and the restriction of u to F is in B. This notion 
of composition is a particular example of the composition operators defined in this 
thesis. 

Hoare, Brookes, and Roscoe [Hoare81aJ extend the work of [Hoare81b] to deal 
with the problems of refusals and nondeterminism. They do this by permitting behaviors 
to be more highly structured objects than just sets of traces. In particular, a behavior is 
a set of pairs <s, X>, where s is a trace, and X is a set of events that can be refused by 
the process after the trace s has been produced. Although they use a single universal 
set of events for all processes, we can imagine designating the set of all events that 
actually appear in a process as the interface of that process. As in the model of 
[Hoare81b], traces play the role of observations. There are "concealment" operators 
for deleting events, and "inverse image" operators that permit renaming of events. 
There are no "direct image" operators, apparently because they are not as well 
behaved as the inverse image operators. Two kinds of parallel composition operations 
are defined: composition by intersection, in which events of the component processes 
are connected, and composition by interleaving, in which the events of the components 
remain independent. 

Rounds and Brookes [Rounds81] attempt to justify and extend the work of 
[Hoare81a] in the following way: A definition of process behaviors is made that includes 
somewhat more information than that of [Hoare8la], and is based on supposedly more 
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fundamental intuitive considerations. A number of algebraic operations, including 
composition and abstraction, are defined on behaviors. A notion of "observable 
equivalence" of behaviors is defined, and is shown to be a congruence. The quotient of 
the algebra of behaviors with respect to this congruence is then shown to be isomorphic 
to the model of [Hoare81a], thus providing evidence that this model exactly captures the 
externally observable properties of processes. 

There seem to be problems associated with the use of models of CSP as a 
semantic basis for specification languages. These problems center around the 
following two questions: (1) Do traces represent a "complete" record of execution of a 
process, or simply some finite portion of such a record? (2) What is the meaning of a 
liveness specification such as "eventually event a will occur," if a process can be 
placed in an environment that refuses to permit the occurrence of event a? 

With respect to question (1), it is difficult to see how the designers of the CSP 
models could have intended traces to represent complete observations. This is 
because in general a complete observation will be infinite, but the CSP models provide 
no method for extracting infinite traces from behaviors. Without a distinction between 
complete and incomplete observations, we have no way to determine whether a 
particular CSP process satisfies a liveness specification. It is clearly ridiculous to 
require that a specification such as "eventually event a will occur" be satisfied by all 
"incomplete" as well as all "complete" observations. 

Question (2) arises from a desire to "assign the blame" for an unsatisfied liveness 
specification, either to a process or its environment. If a process can always be placed 
in an environment that can prevent the occurrence of event a, then the only reasonable 
conclusion we can draw is that the specification "eventually a will occur" is too strong 
(i.e. inconsistent). However, it is not clear how to weaken such a specification so that it 
can be regarded as consistent. 

The above problems associated with the models of CSP have been avoided here 
as follows: First, it is assumed here that the observations in a behavior represent 
complete records of execution. Second, we accept the obvious conclusion that the 
specification "eventually a will occur" is inconsistent with respect to a model (such as 
the model of [Hoare8lb]) that admits the possibility of refusals. Instead of trying to find 
ways to weaken specifications like this so that they can be regarded as consistent even 
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in the face of refusals, though, we construct a model in which refusals are not allowed. 
This is the idea behind the l/O-behaviors constructed in Chapter 5 of this thesis. 

Calculus of Communicating Systems 

Rather similar to the models of CSP discussed above is the "Calculus of 
Communicating Systems," (CCS) of [Milner80]. As in CSP, the notions of a 
communication event and a sequence of communication events are the fundamental 
concepts for describing the behavior of a process. The role of a process interface is 
played, in CCS as in CSP, by the set of communication events in which the process is 
capable of participating. The CCS notion of an observation is a sequence of events; in 
contrast to CSP, CCS admits the possibility of infinite observations. 

To represent the behavior of a process, Milner introduces the notion of a 
communication tree whose paths represent all possible complete histories of 
communication for a process. In a communication tree there can be multiple arcs 
emanating from a single node, labeled with with the same communication event, and 
arcs can be labeled with the special symbol t, which represents an internal aciion of a 
process not associated with any communication event. Communication trees therefore 
contain more information about a process than just a simple set of traces. In fact, 
communication trees contain more information about a process than can be detected 
through composition with other processes. Milner addresses this problem by defining 
several notions of "observable equivalence" of communication trees, and shows that 
these relations are congruences for an algebra of processes whose operations include 
operations of composition and abstraction. He suggests that the class of process 
behaviors be obtained by forming the quotient of the algebra of communication trees 
with respect to one of these congruences. He is unable to reach a conclusion, though, 
as to which of the congruences is "best," or to give explicit characterizations (not 
involving quotient constructions) of the quotient algebras. 

Although communication between two processes in CCS, as in CSP, is 
synchronized in the sense that it is represented by the simultaneous occurrence of 
communication events for the participating processes, communication in CCS is unlike 
that in CSP in the sense that a CCS process cannot prevent another process from 
performing an event. This is because the definition of the composition operation in CCS 
states that, if process A can perform an event a, and process A ' can perform the 
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"complementary" event a ', then the composition A || A ' can perform either a, or a ', or 
the communication represented by the simultaneous occurrence of both a and a '. 

The fact that observations can be infinite in CCS raises the question of whether it 
is possible to define CCS processes that satisfy interesting iiveness properties. 
However, it seems that this possibility is ruled out by Milner's composition operation. 
Milner's composition operation is "unfair" in the sense that there are paths in the 
communication tree corresponding to the composition of two processes along which 
only one of the component processes gets to run. This means that no process can 
satisfy a specification of the form: "eventually a will occur," in an environment that has 
the capability of producing an infinite observation. 

Actors 

One of the earlier event-based models of computation is the actor model [Greif75, 
Hewitt77]. An actor system consists of a collection of primitive computing agents 
(actors), that communicate by passing messages. A computation for an actor system is 
a pat liaiiy ordered set of events, where an event marks the arrival of a message at its 
target. Receipt of a message activates the target actor, and may cause additional 
messages to be issued. The partial order represents a kind of temporal "precedes" 
relationship between events, formed by taking the transitive closure of the union of the 
"causes" relation and the "arrival" ordering, the latter of which linearly orders all events 
with the same target. Hewitt and Baker [Hewitt77] postulate certain laws that must be 
satisfied by the various orders. 

The actor model was originally applied [Greif75] to the specification of 
synchronization problems such as the mutual exclusion and readers/writers problem. 
The specifications are written as axioms that constrain the possible computations of a 
system. The language used, although not formally defined, is essentially a prepositional 
calculus in which the propositions are of the form "e -* e '," which means that event e 
must precede event e ' in any computation of a system satisfying the specification. 
Although no notion of state was used in the specifications, the language has 
nevertheless sufficient expressive power to handle several important examples. 

Subsequent work concentrated on applying the actor model to the specification of 
more complex systems, both distributed and centralized [Yonezawa77]. In contrast to 
the work of Greif, Yonezawa's specifications have a decidedly state-transition flavor, 
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and although proponents of the actor model consistently argue that global state is not a 
well-defined notion for distributed systems, the "situations" used in Yonezawa's 
correctness proofs appear to be just such global states. 

In the actor model, the notion of an actor is generally defined by informal axioms 
and description, which are insufficient to answer the question: "What is an actor?" We 
must know the answer to this question if we wish to obtain a meaningful notion of the 
collection of all actors that satisfy a given specification, and to show the validity of rules 
for deriving consequences of specifications of actor systems. The question of what 
actors are has only recently been dealt with by dinger [Clinger81], who defines actors 
and their computations directly in terms of set-theoretic constructs. It is interesting to 
note that, although actor enthusiasts like to point out that viewing computations as 
partially ordered sets of events captures "true" concurrency better than linearly ordered 
computations, Clinger shows that the laws of Hewitt and Baker are in fact equivalent to 
the existence of a global linear ordering of events in a computation. 

To relate the actor model to the model used in this thesis, we can attempt to 
identify notions of interface, observation, behavior, abstraction, and composition in the 
actor model. There seems to be no obvious notion of the interface of an actor. The 
notion of a partially ordered set of events plays the role of an observation. Roughly 
speaking, Clinger defines the behavior of an actor to be a function that describes the 
actor's response (i.e. its state change and message transmissions) to the receipt of a 
message. Although we can imagine composing a collection of independent actors into 
a composite system, there seems to be no formal notion in the actor model 
corresponding to such an operation. As mentioned above, the existence of the arrival 
ordering prevents the definition of an abstraction operation. 

The actor model has certain defects that render it unsuitable for a theory of 
specification. The major difficulty is that the actor model does not support abstraction 
of systems in a uniform way. There are notions of an actor and a system of actors, but 
no way to view a system abstractly as a single actor. The artificial "arrival ordering," 
imposed on all events that occur at a single actor, is the primary feature that prevents 
abstraction from being defined in a reasonable way. Another reason is the fact that 
every message must contain the name of its target actor, since this means that it is 
never possible to completely suppress the internal structure of an actor system. 
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Lynch/Fischer Processes 

In the model of distributed computation proposed by Lynch and Fischer 
[Lynch81], the primitive objects are variables and processes, and systems of processes. 
A variable is a mailbox-like container for values, and a process is a kind of state machine 
that can perform input and output on variables. A system of processes consists of a 
collection of processes that communicate through variables. The variables of a system 
of processes are partitioned into external and internal variables. There is a kind of 
composition operation that combines a collection of systems of processes to form a 
larger system. There is also a kind of abstraction operation that transforms some of the 
external variables of a system into internal ones. 

A correspondence between Lynch and Fischer's model and the model of this 
thesis can be established, if the notion of an event is identified with Lynch and Fischer's 
notion of a "variable action." A variable action describes the change in the value of a 
variable resulting from a single execution step. The interface of a system of processes 
is the set of all variable actions it can perform. The behavior of a system of processes is, 
as Lynch and Fischer define, the set of all finite and infinite sequences of variable 
actions the system is capable of performing. To view Lynch and Fischer's operation of 
composition of systems of processes as a special case of the composition operators 
defined here, it is necessary to account for the requirement that the actions on a single 
variable in the computation of a system have consistent values. This is easily 
accomplished if variables are thought of as active entities with an interface and a 
behavior. The interface of a variable is the set of all variable actions that can be 
performed on it. The behavior of a variable is the set of all finite and infinite sequences 
of variable actions in which the value read in each variable action equals the value 
written in the immediately preceding variable action. 

In terms of modeling power, the model of this thesis and that of Lynch and Fischer 
appear equivalent. Lynch and Fischer's model is certainly capable of handling 
nondeterminism and liveness properties. The main advantage of the model of this 
thesis over that of Lynch and Fischer is that the former contains fewer primitive 
concepts. It is not necessary to draw distinctions between variables, processes, and 
systems of processes, and the definitions of composition and abstraction are simplified 
by avoiding these distinctions. 
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1.4.3 Temporal Logic Specification 

Several authors [Hailpern80, Lamport83, Schwartz81] have proposed the use of 
temporal logic as a specification language and a vehicle for expressing correctness 
proofs. The use of temporal logic as a specification language evolved gradually from its 
use as an assertion language, that is, as a language for expressing properties of 
program executions [Pneuli77, LamportBO]. There is a subtle difference, though, 
between the semantics appropriate for temporal logic used as an assertion language 
and temporal logic used as a specification language. This difference, which has not 
been explicitly addressed in the literature.can be summarized as follows: Whereas 
temporal formulas as assertions express properties of single computations of a fixed 
program, temporal formulas as specifications express properties of the set of 
computations of an undetermined program. Stated another way, whereas a model for a 
temporal formula used as an assertion about a fixed program is a single computation of 
that program, a model for a temporal formula used as a specification is the set of all 
computations that can be produced by some program. This distinction has important 
ramifications for whal notion of consistency is appropriate in each case. A temporal 
formula used as an assertion about the computations of a fixed program is consistent if 
and only if there exists a computation of that program that satisfies the formula. A 
temporal formula used as a specification is consistent if and only if there exists a 
program, all of whose computations satisfy the formula. 

Another important issue that is not addressed explicitly in literature on temporal 
logic specification is the ability to specify a single module in isolation from particular 
program context. 1 The notion of a program module satisfying a specification in isolation 
must be meaningful if specifications are to effect the beneficial separation between 
module use and implementation. Since extant work does not include the notion of the 
meaning of a specification in isolation, there has been no discussion of the following 
important question: How can we combine independent module specifications to perform 



1. Recent work [Barringer83], performed independently of the work described in this 
thesis, has begun to address some of the same issues, in particular: (1) temporal 
specifications express properties of sets of computations, rather than single 
computations, (2) specifications should have meaning that is independent of an 
enclosing context. 
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a proof of correctness? In particular, in what common language can the proof of 
correctness be expressed, and what deductions in this language are sufficient to imply 
the correctness of the implementation? 

Among the papers on temporal specification of concurrent program modules, the 
approach developed by Lamport [Lamport83] contemporarily with work on this thesis, 
results in specifications that appear most similar to the state-transition specifications 
described here. In Lamport's approach, a specification consists of three parts: (1) A list 
of state functions, which define salient features of the program state; (2) A list of initial 
conditions, which represent assumptions on the initial values of the state functions; (3) 
A list of properties, which constitute the main body of the specification, and which can 
be viewed as standing for a collection of temporal logic formulas. The properties are of 
two kinds: safety properties and liveness properties. Safety properties describe the 
state transitions that are permissible for a program satisfying the specification, and 
liveness properties describe situations under which transitions are required. 

The way one writes a specification in Lamport's approach is quite similar to the 
way one writes state-transition specifications as described in this thesis. At the 
semantic level, though, Lamport's approach seems rather different. The difference can 
be summed up briefly as follows: In Lamport's work, specifications for program 
modules play the role of assertions about the computations of a complete program in 
which the module appears. Whether or not a particular program module satisfies a 
specification can only be determined in such a context. In the framework presented in 
this thesis, whether a program module satisfies a specification can be determined 
without reference to any contextual information. 

The meaning of the state functions used in Lamport's approach is obscure. 
Lamport says that state functions in a specification "should describe information that 
must be contained in the program state of any real implementation." This statement 
apparently implies that the value of the state functions is part of the observable behavior 
of the module being specified, and in this sense is just as important a part of a module 
specification as the relationship between the arguments passed and results returned 
from an invocation of an operation on the module. Choosing state functions that 
provide too detailed a view of the internal operation of a module can result in 
overspecification, since an implementer wishing to satisfy the specification is 
constrained to include enough information in the state so that the state functions can be 



31 



defined. 

This thesis resolves the problem of overspecification by introducing the notion of 
an interface. By defining a module interface, one fixes a particular class of module 
instances (i.e. the behaviors of that interface) which serves as a domain of discourse for 
the temporal specifications. In this thesis, a module interface is a set of events. An 
interface does not contain any notion of module state. States are used merely as a 
device for increasing the expressive power of the specification language to permit the 
desired properties of observations to be expressed in a convenient and natural way. 
Since states are not part of the module interface, the state set in a state-transition 
specification can be chosen on the basis of convenience, without danger of 
overspecification. 

Schwartz and Melliar-Smith have also proposed the use of temporal logic as a 
specification language. In [Schwartz80], specifications are developed for the 
alternating bit communication protocol. Appearing in these specifications are 
uninterpreted symbols such as "InQ" and "OutQ." These symbols, like the state 
functions used by Lamport, are evidently intended to refer to portions of the state that 
must be identifiable in any program satisfying the specifications. Schwartz and 
Melliar-Smith present collections of temporal axioms which they claim completely 
characterize the send and receive processes supporting the alternating bit protocol. 
There is little basis for this claim, since it is impossible to determine what a process is, 
much less determine whether the specifications characterize a particular process or 
class of processes. 

The axioms presented by Schwartz and Melliar-Smith involve complicated derived 
temporal operators such as "latches-unfil," which make the resulting specifications 
quite difficult to understand. The specifications have an ad hoc flavor, and it is difficult 
to obtain insight into how specifications for different examples would be obtained. In 
contrast, the state-transition approach discussed in this thesis suggests a systematic 
way of proceeding from an intuitive conception of the desired module behavior to a 
precise specification. Schwartz and Melliar-Smith present no proof that their send and 
receive process specifications correctly implement the service specification for the 
alternating bit protocol. Experience gained from the examples presented in this thesis 
suggests that specifications that have not been used in a proof of correctness are quite 
likely to contain errors. 
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Hailpern and Owicki [Hailpern80] propose a style of temporal logic specification 
that is different from the styles of Lamport and of Schwartz and Melliar-Smith. Hailpern 
and Owicki also use the alternating bit protocol as an example to illustrate their 
approach to specification. In addition to symbols representing components of the 
internal states of processes in the system, Hailpern and Owicki introduce the notion of a 
history variable, whose value at any instant of time represents the entire history of 
communication between two processes up until that instant of time. They state 
explicitly that history variables are simply a descriptive tool, and are not intended to be 
implemented. History variables appear to be quite useful for writing high-level, 
nonprocedural specifications. For example, the safety properties satisfied by a 
transmission line could be expressed by stating that the history of messages delivered is 
always a prefix of the history of messages sent. 

The state-transition approach to specification presented in this thesis takes the 
history variable idea to its logical conclusion, by allowing arbitrarily structured history 
information (in the form of states), to be introduced into a specification, together with 
operations for manipulating this information. This can he done differently for each 
specification, without change to the underlying semantic model. For example, the 
specification of the reliable transmission module presented in Chapter 6 uses the notion 
of the history of all messages input to the reliable transmission module. In the 
specification of the send protocol module in Chapter 6 it is convenient to define the 
notion of "the history of all messages for which acknowledgements have been 
received." This history is a subhistory of the history of all messages transmitted by the 
send protocol module, and would not be directly accessible in the model of Hailpern 
and Owicki. 

1.4.4 Specification of Communication Protocols 

The problem of specification of communication protocols has received a good 
deal of attention, and can be viewed as a special case of the more general problem, 
investigated here, of specification of modules in a distributed system. Two surveys of 
the protocol specification literature, written from different vantage points, can be found 
in [Sunshine78] and [Hailpern81]. 
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Of the numerous papers on protocol specification and verification, that of 
Bochmann [Bochmann78] appears to be most directly relevant to this thesis. 
Bochmann models a system as a collection of finite-state machines that affect each 
other through coupled state transitions. This is highly analogous to the definition, given 
here, of composition of behaviors by identifying events. Bochmann also has a notion of 
abstraction by ignoring uninteresting transitions, which matches the concept of 
abstraction of behaviors used here. 

Schwabe [Schwabe8la, SchwabeSlb] exploits the analogy between the 
instantaneous state of a communication protocol and a value of an abstract data type, 
to translate state-transition specifications of protocols into equational axioms that 
define an abstract data type. This translation enables him to verify correctness 
properties of communication protocols using an automated verifier (AFFIRM) originally 
intended for proving properties of abstract data types. However, only certain kinds of 
correctness properties can be stated and proved using his technique. In particular, 
liveness properties cannot be handled. Schwabe pays little attention to the semantics of 
his specifications, leaving some ambiguity as to what objects satisfy a specification, and 
what consitutes correctness of a protocol. 

It is interesting that the notions of hierarchy and modularity of systems, and the 
prerequisite concept of the interface of a system with its environment, are much more 
prominent in the literature on protocol specification than they are in the literature on 
specification in general. In protocol specification, a system is viewed as a nested set of 
layers: the bottom level corresponds to the communication hardware, and each layer 
provides an abstract service to the next higher layer. The top level implements the 
service provided to the "end user." Typically the service provided by a level can be 
viewed as an abstract communication network connecting two users, which often have 
an asymmetric sender/receiver relationship. Higher levels of abstraction are 
implemented by interposing protocol processes between the users and the 
communication service provided by the next lower level. The interface between the 
users and a service comprises the set of operations (e.g. open connection, send 
message), they can perform. A distinction is drawn between the specification of an 
abstract service provided to a user (the service specification) and a description of the 
protocol processes (the protocol specification). 
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There are only a few specific correctness properties of interest for communication 
protocols: freedom from deadlock, completeness (i.e. definedness of the protocol in 
every reachable state), progress, and stability in the face of unexpected perturbations of 
the protocol. These properties are certainly also of interest for more general kinds of 
distributed systems. All verification techniques in the communication protocol literature 
are ultimately based on representing the protocol processes and abstract 
communication media as finite-state machines, constructing a combined 
state-transition graph for the implementation, and performing various analyses on this 
graph. The state-transition approach to specification and verification is a natural 
generalization of this technique. It should be noted, however, that the machines used in 
the state-transition specifications in this thesis are not necessarily finite-state, and that 
reachability analysis of a system is performed by proving predicates to be invariant, 
rather than by explicit construction of the combined state-transition graph. This means 
that the proof techniques discussed in this thesis need not be subject to the 
combinatorial explosion problem often referred to in the literature on protocol 
verification. 

1.4.5 Other Concurrent System Specification Techniques 

Chen [Chen81, Chen82] develops a concurrent system specification language 
called EBS (Event-Based Specification Language), and gives specifications for a 
number of examples, including the alternating bit protocol. The EBS language can be 
thought of as a generalized version of the language used in [Greif75] to specify various 
synchronization problems. An EBS specification expresses properties of an event 
history, which is a partially ordered set of events. The EBS notion of an event history 
corresponds to the notion of an observation used in this thesis. 

Chen's work seems to be motivated by a number of the same concerns that 
motivated this thesis. In particular, Chen discusses the distinction between the user's 
view and the designer's or implementer's view of a system, and introduces a notion of 
interface to capture the way in which a system interacts with its environment. In Chen's 
approach, a module interface consists of a collection of ports. There is a notion of 
module interconnection by identifying ports, which is reminiscent of the composition 
operations used in this thesis. Chen's work does not, apparently, include a notion of 
behavior, or the idea that a module specification has meaning except with respect to a 
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complete program context. Chen does not have a semantic definition of the 
correctness of an implementation from which the soundness of proof techniques can be 
derived. Rather, the notion of correct implementation seems to be identified with the 
notion of logical consequence. 

An interesting property of Chen's specifications is that they tend to be 
"orthogonal." An orthogonal specification is a specification that is composed of a 
collection of independent subspecifications. For example, Chen defines a number of 
different properties of a reliable transmission system, such as "no loss of messages," 
"no duplication of messages," and "no erroneous messages." It is not obvious how the 
state-transition technique presented in this thesis could support the writing of 
specifications with a comparable orthogonality property. 

The Gypsy system [Good79, Good82] has some capability for the specification and 
verification of distributed systems. In the Gypsy model, a distributed system is viewed as 
a collection of independent processes that communicate through message buffers. 
Specifications of the communication function performed by a process are expressed in 
terms Of properties of "buffer histories," which represent the sequences of messages 
transmitted on, or received from message buffers. Gypsy seems capable of handling 
only safety properties. 

Correctness proofs in Gypsy are performed by deriving a collection of verification 
conditions from annotated program text, and then proving the validity of these 
verification conditions using a semi-automatic theorem prover. Evidently the validity of 
the verification conditions is taken as the definition of correctness; the literature shows 
no attempt to justify the sufficiency of the verification conditions in terms of any 
fundamental model of computation. Reasoning about the behavior of a system of 
processes in Gypsy is done in terms of relationships between buffer histories. The 
approach appears similar to Hailpern and Owicki's history variable approach. 

An outgrowth of the Gypsy work is the work of DiVito [DiVito82], which is 
concerned with the description and mechanical verification of communication 
protocols. DiVito's specifications contain liveness properties only, and are expressed in 
a decision table style that captures much the same information as the definitions of 
state-transition relations presented in this thesis. The purpose of DiVito's work seems to 
be to quickly reach a point at which experimentation with mechanical verification is 
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possible. His focus is primarily on linguistic issues, rather than their semantics. 

Lansky and Owicki [Lansky83] have developed a language, called GEM, for the 
specification and verification of properties of concurrent systems. The underlying 
model of computation is an event-oriented model similar to the actor model [Greif75, 
Hewitt77], in which a computation of a system is represented as a set of events plus 
various relations on this set. The enable relation captures the notion of necessary 
temporal precedence, or causality, between events. The element partial ordering 
captures the notion of incidental temporal precedence, where one event precedes 
another because they happen to occur at the same point in space. The temporal partial 
ordering is the transitive closure of the union of the enable relation and the element 
ordering. Besides the notion of an event and the relations on events discussed above, 
GEM includes a number of additional primitive notions. An element corresponds to a 
locus of activity or point in space. A group is a set of elements and other groups, which 
is used to collect semantically related objects. History sequences are certain increasing 
sequences of computation prefixes, and are used as a domain of interpretation for 
temporal Ionic formulas. Threads are a mechanism for dynamically grouping a 
sequence of related events. 

The issues considered by GEM seem largely orthogonal to those examined in this 
thesis. The design of GEM seems to have been motivated primarily by a desire to 
describe, within a common framework, the semantics of a number of primitives of 
concurrent programming languages. For example, monitors and the CSP 
communication primitives are discussed. In contrast, this thesis is not concerned with 
the description of programming language primitives, although this is a problem that 
must ultimately be addressed. A GEM specification describes constraints on 
computations of a single program, whereas in this thesis a specification is viewed as 
describing constraints on the entire set of computations of an undetermined program. 
GEM apparently does not include any notion of behavior, composition, or abstraction. 

Yonezawa [Yonezawa77] develops techniques for the specification and 
verification of parallel programs, based on the actor model of computation. The central 
concepts used in these techniques are the notions of a conceptual state, and a 
situation. A conceptual state is a summary of the past communication history of an 
actor, and corresponds closely to the conceptual states used in the state-transition 
specifications of this thesis. A situation assigns a conceptual state to each actor in a 
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system, and is used in verification in much the same way as the state of the "composite 
machine" is used in this thesis (see Chapter 3). The notion of an implementation 
invariant appears in Yonezawa's work, and plays roughly the same role there as it does 
in this thesis. Yonezawa's model seems to incorporate a notion of hierarchy of 
abstraction, in the sense that it is possible to view a system both at a more detailed level, 
where there is a larger collection of events and more detailed states, and at a less 
detailed level, where only a subset of the events is considered and less information is 
contained in the states. 

Yonezawa's specifications look very much like the definitions of state-transition 
relations used here, in the sense that a specification describes, for each possible event, 
a precondition on the state that must hold for an event to occur, and a postcondition 
that describes the state that results after the event occurrence. The semantics of the 
event/precondition/postcondition triples used by Yonezawa seems to differ from their 
counterparts in this thesis, in the sense that if the precondition of an event ever holds, 
then that event must eventually occur. Thus, Yonezawa's formalism appears, to a 
pertain Rxtent. to be capable of expressing liveness properties. 

There are three major deficiencies with Yonezawa's work, which are improved 

upon in this thesis: 

(1) The semantics of Yonezawa's specifications are defined informally in terms 
of the actor model, whose precise definition is somewhat obscure. It is therefore not 
possible to address rigorously the question of what constitutes correctness in 
Yonezawa's model, and to show that his proof techniques suffice to prove correctness. 

(2) The actor model lacks a useful notion of modular decomposition. In 
particular, there is no reasonable way to view a system of actors as a single actor. 

(3) Yonezawa's techniques can handle only a very limited form of liveness 
property in specifications and proofs; namely, those of the form: "If the precondition of 
an event holds, then eventually that event must occur." 
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2. Framework for a Theory of Specification 

The purpose of this chapter is to construct a framework of definitions that is 
suitable as a foundation for a theory of specification. We present and motivate formal 
definitions of the notions, discussed informally in Chapter 1, of "interface," 
"observation," "abstraction," "decomposition," "implementation," and "correctness." 

2.1 Interfaces, Observations, and Behaviors 

An event is an observable instantaneous occurrence during the operation of a 
computer system. If one were to examine a particular computer system in microscopic 
detail, the events of a system could be identified with physical events, such as voltage 
changes on signal lines. However, we are generally not interested in such a large 
amount of detail, and instead regard large classes of physical events as equivalent and 
indistinguishable. Examples of such equivalence classes are: the event in which 
process A submits a message to a transmission system for delivery to process B, the 
event in which the variable x is set to three, and the event in which the synchronizer 
module receives a try request from user process p. 

The first step in modeling a particular system is to identify and classify the 
interesting instantaneous occurrences. As a result of this procedure, we associate with 
each system and each particular level of abstraction at which the system is to be 
viewed, an "interface," which represents the set of ail possible instantaneous 
occurrences of interest at the given level of abstraction, plus a single element X, which 
represents all uninteresting occurrences. Lower levels of abstraction (those that 
incorporate more detail) are characterized by larger interfaces, corresponding to finer 
classifications of the instantaneous occurrences, whereas higher levels of abstraction 
are associated with smaller interfaces, corresponding to coarser classifications. 

Definition - An interface is a structure <£, X £ , ...>, where E is a set whose elements are 
called events, X e is a distinguished element of E called the null event, and the ellipsis 
indicates that further structure may be present. I 

We use the symbol E to denote both the entire structure and the underlying set of 
events. When the interface £ is clear from the context, we will omit subscripts, writing X 
instead of X c . 
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In general, an interface £ will have additional structure besides the distinguished 
element X £ . For example, in Chapter 5 we will be concerned with interfaces of the form 
<£, X E , ln £ , Out £ >, where ln E and Out e are subsets of £ called the sets of "input events" 
and "output events," respectively. Except for the material in Chapter 5, the only 
structure required is the existence of the distinguished null event X £ . 

If £ is an interface, then let £* denote the set of all finite strings, and £°° the set of 
all finite and infinite strings, on the alphabet £ - {X £ }. It is convenient to view £ as a 
subset of £• and £°°, where the element X £ of £ is identified with the unique string of 
length zero, and each non-\ element e of £ is identified with the corresponding string e 
of length one. 

In the synchronizer example, the interfaces are defined as follows. Let Proc be the 
set of user processes. The synchronizer module has interface E m = {try p , run p , rest p : p 
€ Proc} U {X}. A synchronizer component module has interface E 50 = {X, try. run, 
rest, tokenjn, token.out, requestjn, request_out}. 

To rifificribe the functioning of a system during a single e*<>c<.'tion, w e postulate 
the existence of an omniscient observer, outside of the system under consideration. 
The observer is able to watch the operation of the system and compile a complete 
record of the events that occur, along with their time of occurrence. We refer to this 
record, the structure of which will be precisely defined below, as an "observation." An 
observation is a function that maps each instant of time f in the interval [0, oo) to the 
event that occurs at time t . 

We assume that at most finitely many non-X events can occur in any bounded 
interval. This assumption, which is used to permit inductive reasoning about 
observations, seems reasonable if we think of a computer as executing in discrete steps 
taken at a finite rate. The fact that an observation is a (single-valued) function implies 
that at most one event occurs at each instant of time. This is not to be interpreted as a 
fact about real-world systems, but rather as part of the definition of the term "event." 
That is, by definition no more than one event occurs at any instant. To model a situation 
in which a number of primitive occurrences can happen simultaneously, we must use an 
interface that contains one event for each possible combination of primitive 
occurrences. 
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The reason why we define observations as functions from [0, oo) to events rather 
than simply as sequences of events (and in Chapter 3 define computations on [0, oo) as 
well), is a technical one. We shall often be interested in composing a collection of 
observations, one for each component module in a system of modules, to obtain a 
single observation of the composite system. If observations are defined to be 
sequences of events, then composition of observations corresponds (in the special 
case that the component modules do not interact) to interleaving of sequences. For 
example, if a module M 1 can produce the sequence of events ab and module M 2 can 
produce the sequence of events cd, then the composite system consisting of modules 
M, and M 2 can produce the interleaved sequence of events acbd. The feature of 
interleaving that is inconvenient for our purposes is the fact that the indices of events 
change under interleaving. That is, the event b appears as the second event in the 
sequence ab, but as the third event in the sequence acbd. The definitions of 
observation and composition we use have the more convenient property that an event 
appearing at time t in an observation for module in isolation always corresponds to the 
event appearing at time t in a composite observation. 

Definition • An observation over an interface £ is a function x: [0, oo) -* £, such that 
x(f) * X for at most finitely many / in each bounded interval. I 

Let A denote the identically X observation, and let Obs(E) denote the set of all 
observations over £. If x € Obs(£), and a € [0, oo), then let [x] denote the function that 
maps each f € [0, oo) to the the (finite) string of non-X events that occur during the 
interval [0, f) in x. Let suffix a (x) be the observation y € Obs(£) such that y(t) = x{t + a) 
for all f€ [O.oo). 

By collecting the set of all observations that can be produced by a system in 
various environments, we obtain the "behavior" of that system. 

Definition • A behavior of interface £ is a subset of Obs(£). 

Let Beh(E) be the set of all behaviors of interface £. 
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2.2 Abstraction, Decomposition, and Interconnection 

In this section, we show how the concepts of hierarchy of abstraction and modular 
decomposition can be captured through the use of certain mappings between 
interfaces, which we call "translations," and the corresponding mappings they induce 
on observations. 

Definition - A translation from an interface E to an interface F is a function h: E -* F 
such that h(X E ) = \ F A translation h from £ to F extends in a natural way to a function 
h: Obs(£) -» Obs(F), under the definition h(x) = h"x. I 

The concept of an "interconnection," defined below, is the formal notion 
corresponding to a diagram like Figure 2. Intuitively, an interconnection consists of of 
an "abstraction map," which captures the relationship between a more concrete and a 
more abstract view of a system, and a "decomposition map," which captures the 
relationship between a composite system and its component modules. An abstraction 
map is simply a translation from the interface corresponding to the concrete view, to the 
interface corresponding to the abstract view. A decomposition map is a collection of 
translations that shows how the events for the composite system are decomposed into 
events for the component modules. 

Definition - An interconnection is a pair 3 « < a 3 , <« / 5 >, G >, where a 3 : E 5 — D 3 is a 
translation, / is a finite index set, and each 8 3 : E 3 -+ F 3 is a translation. The interfaces F, 
are the component interfaces of 3, the interface £ 3 is the composite interface of 3, and 
the interface D 3 is the abstract interface of 3. The translation o 3 is the abstraction map 
of 3, and the vector <5 3 >, e/ is the decomposition map of J. I 

In the sequel, underlining will be used to denote a vector of objects; thus we write S. 3 for 
the vector <fi 3 > /€/ . 

The synchronizer implementation yields an example of an interconnection. The 
content of Figure 2 is formalized by the interconnection <o SMI , S. SMI >, where E 8 *', a^': 
£ smi _> £ sm and 5 smi. £ smi _ £ sc p £ p roc are defined below. 

The composite interface for the synchronizer module implementation is E SMl = 
{try. run . rest , token , request : p € Proc} U {X}. 
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The decomposition map £ SMI projects or decomposes each event for the 
composite interface into corresponding events for the synchronizer component 
modules. The events try , run , and rest in E^ 1 decompose to try, run, and rest events 
of the pth synchronizer component module. The events token and request of £ SMI 
represent interaction between the pth synchronizer component module and its 
neighbors in the ring. Specifically, the event token represents the joint occurrence of a 
tokenjout event for the pth synchronizer component module, and and a token Jn event 
for the p + 1st synchronizer component module. Similarly, the event request p represents 
the joint occurrence of a request jout event for the pth synchronizer component module 
and a request Jn event for the p-1st synchronizer component module. Formally, 



fSMI 

= run, ife = run 



fi| M, (e) = try, if e = try p 



p 
= rest, if e = rest 

= tokenjn, if e = token_ H 

= token_out, if e = token,, 

p 

= requestjn, if e = request t 
= request_out, if e = request 
= X, otherwise. 

The abstraction map a^ Ai preserves events in which the system of synchronizer 
component modules interact with the user processes, but deletes (i.e. maps to X) events 
corresponding to internal interaction between synchronizer component modules. 
Formally, 

a^'fe) = e, if e € {try p , run p , rest p : p € Proc}, 

«s X, if e € {token p , request^: p € Proc} U {X}. 

We assign intuitive significance to some of the operators on behaviors that are 
naturally induced by abstraction and decomposition maps. 

The direct image operator associated with an abstraction map takes a behavior of 
a system viewed at a more concrete level, and produces the corresponding behavior of 
that system viewed at a more abstract level. 

Definition - The abstraction operator associated with a translation a: E -*■ D, is the 
function, also denoted by a, that maps each behavior 6 € Beh(f) to the direct image 
a(B) € Beh(O). We refer to the behavior a{B) as the abstraction of B under a. I 
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The inverse image operator induced by a decomposition map models the 
operation of composing a collection of component module behaviors to produce the 
corresponding behavior of the composite system. Intuitively, if S is a system consisting 
of component modules <M> ia , then S can produce all and only those observations x 
that, when decomposed, match observations that each M s can produce. 

Definition - The composition operator associated with the vector £ of translations is 
the function, denoted by £ \ that maps a vector <B,> /€/ , where B, € Beh{F) for each / € /, 
to a behavior fi' 1 (B_ ) € Beh(E), under the definition: 

«" 1 (fi ) = {x € Obs(E): tyx) € B, for all / € /}. 
Thus, the set £ 1 (B. ) contains an observation x € Obs(E) iff fi ; (x) € B. for all / € /. We call 
this set the composition of fl under S. • ■ 

2.3 Specification, Implementation, and Correctness 

In practice a specification will take the form of a string of symbols in a formal 
specification language, since it must be possible to write down a specification. 
However, since this thesis is not concerned with the details of a particular formal 
language in which specifications are to be expressed, it is convenient to adopt a more 
liberal view: A specification is any mathematical object that denotes, in a well-defined 
way, an interface and a set of behaviors of that interface. 

Definition - A specification language is a triple <Specs, 8, $>, where Specs is a set of 
specifications, 6 is a mapping that assigns an interface 6(S) to each specification S € 
Specs, and a is a mapping that assigns a set $(S) C Beh(S(S)) to each specification S € 
Specs. We say that S is a specification of interface 6(S), and that each B € a(S) satisfies 
S. I 

An interconnection describes the pattern of interaction between modules in a 
system in analogy to the way a program scheme describes the flow of control between 
uninterpreted statements. It makes no sense to speak of an interconnection as 
"correct" or "incorrect," since an interconnection includes no information about the 
behaviors of the component or abstract modules. However, if we provide an 
interpretation for the modules by augmenting an interconnection with specifications of 
the abstract and component module interfaces, it does become meaningful to speak of 
correctness. We use the term "implementation" for an interconnection augmented with 
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specifications. 

Definition - An implementation is a tuple <5, S ab8 , <S> /€/ >, where 3 is an 
interconnection, S abs is a specification of interface D 3 , and S, is a specification of 
interface /=?, for each /' € /. I 

An implementation is correct if, whenever acceptable behaviors are plugged in for 
the component modules, then the resulting abstract module behavior is also 
acceptable. The composition and abstraction operators associated with the 
interconnection formalize the notion of "plugging in." 

Definition - An implementation <S, S^, <S,> /€; > is correct if a 5 »(l 3 ) 1 (B_ ) € a ( S abs)' 
whenever 8, € <&{S) for each /€ /. I 
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3. State-Transition Specifications 

In this chapter, we will investigate a particular approach, called "state-transition 
specification," to the derivation of module specifications. In this approach, we imagine 
that at any instant of time a module can be thought of as being in one of a number of 
conceptual states. Associated with each conceptual state is a collection of events that 
can occur in that state, and a description of the state change that results from the 
occurrence of each of those events. Thus, a state-transition specification describes the 
desired functioning of a module in terms of a kind of machine that generates an 
observation as it executes. It is important to note that the conceptual states in a 
state-transition specification are merely a tool for describing the desired functioning, 
and need not have anything to do with the "real" state present in any particular module 
instance that satisfies the specification. 

The properties captured by the state-transition technique discussed here are 
divided into two classes: "local" properties, which concern the relationship between an 
event and the conceptual state of the module immediately preceding and immediately 
following the occurrence of that event, and "global" properties, which relate events and 
states perhaps distant from each other in time. Local properties are of the form: "An 
event e can occur only if the state of the module satisfies P, and if e occurs, then the old 
state and new state of the module are related by the binary relation f?." Examples of 
global properties are "eventuality" conditions of the form: "If the module is now in a 
state with property P, then eventually event e will occur." Local properties are specified 
by a machine as mentioned above. Global properties are specified by defining a set of 
"validity conditions" on computations of the machine. The set of computations that 
satisfy the validity conditions is called the set of "valid" computations. 

The reason for investigating state-transition specifications is that they appear to 
provide a natural, straightforward strategy for turning an intuitive understanding of the 
desired function of a module into a formal specification. This strategy consists of the 

following steps: 

(1) Define an appropriate set of conceptual states. For example, in the 
specification of the abstract synchronizer module, a state is a vector that tells for each 
user process whether the synchronizer module thinks that process is trying, running, 
resting, or in error. 

(2) Define a set of initial states, in which the module begins execution. For the 
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synchronizer module, there is a single initial state in which all user processes are 
resting. 

(3) Define, for each event, the conditions required on the state for the 
occurrence of that event to be possible, and the state changes associated with an 
occurrence of that event. For example, a "run" event for process p can occur only if p 
is trying and no other process is currently running. Occurrence of a "run" event causes 
the state of p to change to "running" and leaves the states of all other processes 
unchanged. 

(4) Define the desired global properties for the module. For the synchronizer 
module, we wish to require that every user request eventually result in a corresponding 
reply, if possible. 

Besides serving as a natural vehicle for formalizing specifications, the 
state-transition approach also provides a strategy for performing correctness proofs. 
The Correctness Theorem (Theorem 3.9) gives sufficient conditions for correctness that 
exploit the machine structure of the specifications. 

This chapter is organized as follows: In Section 3.1 the notion of "subset 
specifications," of which state-transition specifications are an example, is introduced. 
In Section 3.2 the machines used in state-transition specifications are defined, and in 
section 3.3 some tools for reasoning about their computations are developed. The 
notion of a state-transition specification is defined in Section 3.4. In Section 3.5 the 
Correctness Theorem, which is the main result of this chapter, is proved. Section 3.6 
shows that the Correctness Theorem is a natural generalization of the "possibilities 
mapping" proof technique of Lynch [Lynch83] and Goree [Goree81]. Section 3.7 
shows how the proof technique suggested by the Correctness Theorem can be further 
systematized in the case of state-transition specifications whose sets of valid 
computations have been defined by "relyVguarantee-conditions." 

3.1 Subset Specifications 

As discussed in Chapter 2, a specification S of interface E defines a set a(S) of 
behaviors of interface E. In general, we might look for specification techniques that are 
capable of expressing arbitrary properties of behaviors. However, in practice it appears 
that the properties of behaviors we wish to express in a specification are nearly always 
of a special form. That is, it is nearly always the case that we wish to express universal 
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properties of the observations in a behavior, of the form: "Every observation x in B has 
property P," where P is a property of observations. This means that in practice it is 
usually not necessary to have a specification technique that is powerful enough to 
express arbitrary properties of behaviors. Rather, a less powerful technique, which is 
capable only of expressing properties of observations, suffices. The state-transition 
specification technique introduced in this chapter is of this less powerful variety. 

Definition - A specification S of interface £ is a subset specification if there exists a set 
0(S) C Obs(E) such that S(S) = {B € Beh(f ): 8 Q 0(S)}. I 

For the rest of this thesis we will be concerned only with subset specifications. To 
see what we give up by restricting our attention to subset specifications, let us consider 
some examples. Examples of properties of behaviors that can be expressed as subset 
specifications, that is, as universal statements about observations in a behavior B, are 
the following: 

- Every observation in B contains at most finitely many occurrences of non-X 
events (that is, computation always quiesces). 

- In every observation in S, either each occurrence of a try event for process p 
is ultimately followed by a run event for process p, or else there is a point in time after 
which some process is in the "running" state forever. 

Examples of properties of behaviors that cannot be expressed as subset 
specifications, and hence cannot be captured by the state-transition approach 
discussed here are: 

- There exists an observation in fi that contains at most finitely many 
occurrences of non-X events (there exists a quiescing computation). 

- If x is an observation in B and t € [0, oo), such that [x](t) = u, then there is an 
observation y € B and a t ' € [0, oo) such that [y](t ') = ue. (if the module is capable of 
doing u, then it is also capable of doing ue). 

- If x is an observation in S, and / is an order-isomorphism from [0, oo) to 
[0, oo), then x°/ is also an observation in B (the module is asynchronous, or 
timing-independent). 

Because the properties of behaviors defined by subset specifications are really 
just "lifted" properties of observations, the definition of correctness of an 
implementation that involves subset specifications has an equivalent statement in terms 
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of observations. 

Lemma 3.1 - Suppose that <5, S abs , <S / > /€/ > is an implementation, where S abs and each 
S,. is a subset specification. Then <5, S abs , £ > is correct iff a 3 «(£ 5 )\<0{S)> iC ) C 0(S abs ). 

Proof - = > Suppose <5, S abs , & > is correct. Suppose that x € Obs(E 3 ) is such that 5 3 (x) 
€ 0(S # .) for each / € I. Then the behavior {x} is the composition under £ 3 of the vector of 
behaviors <{S 3 (x)}> €/ , and the behavior (a 3 (x)} is the abstraction under a 3 of the 
behavior {x}. Since the behavior {6 3 (x)} satisfies S t for each /' € /, it follows by 
correctness that the behavior {a 3 (x)) satisfies S aba . Thus a 3 (x) € OiS^). 

< - Suppose that a 3 °(£ 3 )' 1 (<0(S,)>, €/ ) c 0(S abs ). For each / € /, suppose that B, is 
behavior that satisfies S r Then B. Q 0(S ( ). Let B abs ■ a 3 °(£ 3 )" 1 (B_ ). Then B abs is a 
subset of 0(S ab8 ) by hypothesis, and hence Hence B^ satisfies S abs . I 

3.2 Machines and Computations 

In this section, we define a kind of nondeterministic machine that generates an 
observation in each of its computations. 

Definition - A nondeterministic event machine (or just "machine" for short) M consists 
of: 

- An interface E M 

■ A set Q M of states. 

- A nonempty set lnit M Q Q M of initial states. 

- A relation Trans„ C Steps(£„, J = O u xf u x Q„, called the 
state-transition relation, such that for all q € Q M , the null step <q, X, q> € Trans w . I 

If E M = E, then we say that M is a machine of interface E. 

The state-transition relation Trans w of a machine M has a natural extension 
Trans M * that applies to strings of events, rather than just single events. Formally, define 
Trans * CQ u x E* X Q u to be the least relation containing Trans M , and having the 
following closure property: If <g, u, r> € Trans w * and <r, v, s> € Trans w *, then <q, uv, s> 
€ Trans w *. (Recall from Section 2.1 that we identify the null event X £ with the empty 
string.) 
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Definition - A state q € Q M is reachable by M if there exists a state q € lnit M and a 
string u € E M * such that <g , u, q> € Trans M *. 

Suppose that R C O w . Then f? is inductive for A/f if 

(D lnit w CK. 

(2) For all <q, e, r> € Trans M , if g € fl then r € /?. 
We say that /? is invariant for M if it contains all reachable states of M. The following 
extremely important induction principle is a standard technique (see, e.g. [Keller76]) for 
proving properties of reachable states. 

Lemma 3.2 (Induction Principle) - Suppose M is a machine, and that R C Q M . If R is 
inductive for M then R is invariant for M. 

Proof - Straightforward. I 

Ordinarily, a computation of a machine might be defined to be a pair consisting of 
a state sequence q , q v ... , and an event sequence e , e 1t ... , such that each step 
<n p n > satisfies the state-transition relation. Intuitively, q k and q k + 1 represent the 
states "just before" and "just after" the occurrence of the event e k , respectively. To 
define a computation in which the notion of an event sequence has been replaced by 
that of an observation, we generalize the notion of a state sequence to that of a "state 
function," which assigns a state to each nonnegative real number, in such a way that 
the notion of state "just before" and "just after" each point t € [0, oo) is meaningful. 

Definition - A state function over a set of states Q is a function f: [0, co) -* Q such that 
for all f € [0, oo), there exists t t > such that / is constant on the intervals [f-e,, t] n 
[0, oo) and (f, t + *,]. I 

We write f(t * ) as an abbreviation for the constant value of f on the interval (t , t + e,), 
which intuitively represents the state "just after" time f. The state at and also "just 
before" time t is represented by the value /(f). 

Definition - A history over an interface E and state set Q is a pair X = <Obs x , State x >, 
where Obs x is an observation over £, and State x is a state function over 0. Let 
Hist(£, Q) denote the set of all histories over interface E and state set 0. I 
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If X € Hist(£, Q) and t € [0, oo), then define the step occurring at time t in X by: 
Step x (f) = <State x (0,Obs x (f),State x (f + )>. 

The generalization of the ordinary definition of a computation is now 
straightforward. 

Definition - A computation of a machine M is a history X € Hist(£ M , Q M ) such that 

(1) State x (0) € lnit w . 

(2) Step x (0 € Trans w for all r € [0, oo). 

Let Comp(Af) denote the set of all computations of M. I 

If V is a set of computations of M, then define Obs(V), the set of all observations 
generated by V, by Obs(V) = {Obs x : X € V}. 

3.3 Properties of Histories 

The purpose of this section is to develop some machinery for passing back and 
forth between histories and "history skeletons," which are sequences of steps plus 
timing information. Each history skeleton naturally defines a unique history. 
Conversely, given a history X we can extract (though not in a unique way) a history 
skeleton by restricting Step x to a suitable subset T of [0, oo). Whereas histories have 
convenient behavior under projection, history skeletons are more useful for performing 
computational induction arguments. 

Definition - A skeletal sequence is a monotone increasing sequence f < f 1 < ... of 
elements of [0, oo), such that t Q ■ and t k -*■ oo as k — oo. A skeletal sequence T = 
<t k > k £j( spans a history X if for each k € X, Obs x is identically X and State x is constant on 
the interval (t k , t k + 1 ). I 

Note that by the properties of a state function, if State x is constant on the open interval 
(t k , t k + 1 ), then State x is also constant on the right-closed interval (f A , t k + 1 ]. 

Lemma 3.3 - Suppose X is a history. Then there exists a skeletal sequence that spans 
X. 

Proof - Let T = Jf U {/ € [0, oo): Step x (f) is nonnull}. The proof that T is a skeletal 
sequence that spans X uses the defining properties of observations and state functions, 
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plus the compactness property of the closed, bounded subsets of [0, oo). The details 
are omitted. I 

Corollary 3.4 - Suppose <X.> e/ is a finite collection of histories. Then there is a 
skeletal sequence T that spans all the X r 

Proof - For each / € /, let T. be a skeletal sequence that spans X,, and define T = U /€ , T r 
The finiteness of / implies that T has order type u, and is hence a skeletal sequence. It is 
obvious that T spans each X,. I 

Definition - A history skeleton over an interface £ and a state set is a function f: T -*■ 
Steps(£, 0), where T = <t k > k£j( \s a skeletal sequence, such that if f{t k ) = <q k , e k , r k > for 
each k € X, then r h = q k + , for all k € X. The history skeleton f spans a history X if T 
spans X and f is the restriction of Step x to T. I 

Lemma 3.5 - Suppose that / is a history skeleton over £ and Q. Then there is a unique 
history X over £ and such that / spans X. 

Proof - Suppose f:T-+ Steps(£, 0), where T = <i k > k€JC Suppose f(t k ) = <q k , e k , q„ + 1 >. 
The requirement that / spans X defines X uniquely: 

Obs x (f) =e„, \tt = t k 

=■ A, otherwise. 

State x (f) = g , iff * 

-<»**v K ' € C'*. f* + ti- 
lt is easy to see that X is a history. I 

Lemma 3.6 • Suppose X is a history over £ and 0. If T » <f A > AeJf is a skeletal sequence 
that spans X, then the restriction of Step x to T is a history skeleton that spans X. 



Proof - Let f denote the restriction of Step x to T, and suppose that f(t k ) = <q k , e k , r k >. If f 
is a history skeleton, then / spans X by definition. To see that f is a history skeleton, we 
must show that r k « q A + 1 for all k £ X. Fix * € X. By definition of a state function, we 
can select t > such that State x is constant on the interval (f., f.+cl. Then r = 
State x (r k + c). Since State x is constant on the interval (t k , f A + 1 ] by the fact that T is a 
skeletal sequence of X, it follows that r k * q k I 
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The following consequence of Lemma 3.3 and Lemma 3.6 says that every state 
appearing in a computation is reachable. 

Corollary 3.7 - Suppose X is a computation for a machine M. Then State x (f) is 
reachable for M, for all f G [0, oo). 

Proof - Use Lemma 3.3 to obtain a skeletal sequence 7 = <f*> fc€ jf that spans X. By 
Lemma 3.6, the restriction of Step x to 7 is a history skeleton that spans X. The result 
follows by an inductive proof that the constant value of State x on each set {f }, (t v t 2 ], 
(r , f ], ... is reachable for M. The details are straightforward, and are omitted. I 

3.4 State-Transition Specifications 

Definition - A state-transition specification S of interface E is a pair <W S , V s >, where M s 
is a machine of interface E and V s is a set of computations of M s , which we call the set 
of valid computations. I 

!f S is a state-transition specification of interface E, then the set of behaviors that 
satisfy S is defined as follows: 

S(S) = {B € Beh(E): B C Obs(V s )} 
It is clear from this definition that state-transition specifications are subset 

specifications. 

As a concrete example of a state-transition specification, consider the 
specification for the synchronizer module. The interface for the synchronizer module is 

defined by: 

E*** = {\} U {try p , run pI rest p : p € Proc}. 
The state set Q SM for the synchronizer module specification is defined by 

0^ = n CDrnr . {trying, running, resting, error}. 
Thus each element of the state set 0^ is a vector that tells, for each process p € Proc, 
what the synchronizer module thinks that process is currently doing. If q € Q m and p € 
Proc, then let g(p) denote the component of q corresponding to process p. If v € 
{trying, running, resting, error}, then let q[v/p) denote the state r € Q 5 * that is identical 
to q except that r(p) = v. 
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Next, we define the initial state set Init^ and state-transition relation Trans SM for 
the synchronizer specification. The initial state set lnit SM consists of the single state q 
that assigns the value "resting" to each p € Proc. The state-transition relation Trans SM 
contains a step <q, e, r> iff either e = X and q = r, or one of the conditions (try), (run), or 
(rest) below is satisfied for some p € Proc: 
(try) e = try , and either 

q(p) = resting and r = q[trying/p], or 
q{p) * resting and r = q[error/p]. 

(run) e = run p , q(p) = trying, q{p ') * running for all p ' € Proc - {p}, 
and r = q[running/p]. 

(rest) e = rest pl and either 

q{p) = running and r = q[resting/p], or 
q(p) * running and r = q[error/p]. 

We have defined the machine M^ ■ <f SM , 0^, Init^, Trans^ for the 
synchronizer module specification. To complete the state-transition specification of the 
synchronizer module, we must define the set V®* of valid computations of Af^. The 
intuitive property we wish to capture by this definition is that the synchronizer must 
eventually grant all requests, if possible. The qualification "if possible" is required since 
if one user process remains in the "running" state forever, then it will be impossible for 
the synchronizer module to grant any further requests, without violating the mutual 
exclusion property. We can informally state the defining property of V^ as follows: "If, 
for all user processes p, every instant of time at which p is running is eventually followed 
by an instant of time at which p is not running, then, for all p, every instant of time at 
which p is trying is eventually followed by an instant of time at which p is running." 

The validity condition for the synchronizer module is relatively simple, but already 
the locutions used to precisely define this condition are somewhat awkward. To deal 
with more complex specifications, we require a more compact notation that can be 
systematically applied, as opposed to the ad hoc approach taken above. Such a 
notation is developed in the next chapter, where the constructs of temporal logic are 
used to express properties of histories. 
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3.5 The Correctness Theorem 

In this section we consider the problem of how to prove the correctness of an 
implementation with respect to state-transition specifications. The fundamental result 
of this section is the Correctness Theorem. This theorem shows how the correctness of 
an implementation follows from certain properties of a composite machine, which is a 
kind of a kind of product of the machines for the component module specifications and 
the machine for the abstract module specification. Associated with this product 
construction are projection maps that take each computation for the composite 
machine to a corresponding computation for the abstract module machine and for each 
component module machine. 

The Correctness Theorem states that, for an implementation to be shown correct, 
It suffices to show that two conditions hold for the composite machine. We call these 
conditions the "maximality" condition and the "validity" condition. The maximality 
condition concerns the relationship between the state-transition relations of the 
component module machines and the state-transition relation of the abstract module 
machine. The validity condition concerns the relationship between the set of valid 
computations for the component modules and the set of valid computations for the 
abstract module. , 

If the inclusion of the machine from the abstract module specification as a part of 
the composite machine seems somewhat strange, consider the following analogy: In 
proofs of concurrent program correctness using Hoare-like deductive systems [Apt81, 
Owicki76], it is well known that it is sometimes necessary to introduce "ghost 
variables," which have no effect on the execution of the program, but merely serve to 
capture information about the state of program execution not reflected in the values of 
the program variables. The abstract module part of the composite machine serves the 
same function as ghost variables: namely to capture information about the history of 
system execution possibly not reflected in the states of the component module 
machines. 

The proof technique suggested by the Correctness Theorem seems closely related 
to the "data refinement proofs" of [Jones81]. Jones shows how the correctness of 
implementations of data abstractions can be performed via "representation relations," 
which relate the states of abstract data objects to states of their concrete 
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representations. Representation relations capture the same information as the 
"implementation invariants" defined below, and the "possibilities mappings" of Lynch 
[Lynch83] and Goree [Goree81] (see Section 3.6). 

We now define precisely the notion of the composite machine for an 
implementation. Suppose <5, S abs , <Sj> ie j> is an implementation, where S^ = 
<M abs , V^J and S, = <M /t Vj>, for each /' € /, are state-transition specifications. 

Definition - The composite machine M for the implementation <J, S abs and £ > is 
defined as follows: 

Let w abs and n t , be the canonical projection maps from the cartesian product Q M onto 
the factors Q u and Q u , for each / € /. 

,nit A, = ,nit M ab8 X n /€/ »"%■ 
Trans M = {<g, e, r> € Steps(£ M , Q M ): 

<w abi (Q), «(e), » aba (0> € Trans M and 

■bs 
<ir,{q), fi,(e), w y (r)> € Trans w for all / € /}. I 

Suppose that X € Hist(£F M , Q M ). Then associated with X is its canonical projection 
X (abs) onto Hist(£ M ,0„ ), defined by 

Obs x (abs) = aObS x 

State x (abs) =s » ab9 »State x . 

In a similar way, we associate with X its canonical projection X w onto Hist(E M , W ), 
defined by 

Obs x (/) = S^ObSj, 

State^o = w ; »State x . 

It is easily verified that the projections X (,bs) and X w defined above are, in fact, 
histories. Also, it is easily checked that if X is a computation of M, then X {abs) is a 
computation of M abs , and X w is a computation of Af ; , for each / € /. 

Next, we state the conditions that are shown by the Correctness Theorem to be 
sufficient for <3, S^, £ > to be correct. Intuitively, the maximality condition states that 
the abstract machine can perform any event that can be performed by the system of 
component module machines. The validity condition states that a computation that is 
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valid for each of the component modules is also valid for the abstract module. 

Definition - The maximality condition holds for the implementation <J, S abs , £ > if for all 
states q reachable for the composite machine M t and all e € E, if S f (e) is enabled for M f in 
state vj[q) for each /' £ /, then o(e) is enabled for M ab8 in state ir^q)- ■ 

Definition - An implementation invariant for the implementation <3, S abs , £ > is a set Inv 
C Q u , such that Inv is inductive for the composite machine M. I 

Note that an implementation invariant is indeed invariant for M by the Induction 
Principle (Lemma 3.2). 

Since an implementation invariant contains all reachable states of the composite 
machine, it is sufficient to use "g € Inv, where Inv is an implementation invariant," in 
place of "g reachable for the composite machine," in proving that the maximality 
condition holds. 

Definition - The validity condition holds for the implementation <5, S ab8> £ > if: 
Whenever X is a computation for the composite machine M with the property that X w € 
V, for all / € /, then X (ab!l > € V abs as well. I 

We now come to the main technical lemma (Lemma 3.8 below) used to prove the 
Correctness Theorem. The intuitive content of this lemma is as follows: Suppose we are 
given a collection X. of computations for the component module machines, which are 
"coherent" in the sense that there is a single observation x € Obs(E) such that each 
Obs y is the image of x under the mapping 8.. The vector X_ of computations can be 
thought of as a computation of the system of machines, obtained by juxtaposing the 
machines for the component module specifications, and "interconnecting" their events 
as specified by the decomposition map £ . Lemma 3.8 asserts that, if the maximality 
condition holds, then it is possible to construct a computation X for the composite 
machine M, such that Obs x = x, and furthermore, such that the projections X w of the 
computation X are the given original computations X r Since X (ab9) must be a 
computation of the abstract module machine (because every computation of M projects 
to a computation of M^), it follows that every coherent collection & of computations for 
the component module machines, "simulates" some computation of the abstract 
module machine. 
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Formally, suppose that X. is a computation of M., for each /' G /. Given an 
observation x € Obs(£), we say that the collection X_ is x-coherent if Obs x = «,(x) for 
each / € /. The point of this definition is that a vector £ cannot be used to form a 
computation X of M unless the observations of each of the X. are in agreement. 

Lemma 3.8 • Let <5, S abs , <S / > /C/ > be an implementation, where S abs = <M abs , V abs >, and 
that S. = <M r Vl>, for each / G / are state-transition specifications. Suppose that the 
maximality condition holds for <5, S abs , £ >. Suppose that x € Obs(£ 3 ), and that X ; is a 
computation of M f for each / G /, such that the collection K is x-coherent. Then there 
exists a computation X of the composite machine M such that Obs x = x, and such that 
X w = X. for each i G /. 

Proof - By Corollary 3.4, there exists a skeletal sequence 7 « <t k > k€ x that spans each 
of the X r We assume without loss of generality that 7 includes all points t for which x(f) 
* X. Let e k = x(t k ) for each k. We will use the maximality condition to construct a 
sequence q , q v ... of elements of Q M such that v£q k ) = State x (f fc ) for all /' G / and all k G 
X and such that <q k , e k , q A + 1 > C Trans M for ail k G X. Then the fuiiction /: 7 — 
Steps(£ M , M ) that takes t k to <q k , e k , q a + 1 > is a history skeleton for M. By Lemma 3.5 
there is a unique history X for M such that f spans X. It is easy to see that X is a 
computation of M with Obs x = x and X w * X, for each / € /. 

The q k are constructed by induction on k. At the /cth stage of the construction (k > 
0), we assume that q k has been constructed so that q k is reachable and w,(g A ) « 
State x (t k ) for all / € /. We construct q k + , so that w,^ + ,) = State x (f k + ,) for all / € / and 
so that <q k , e k , q fc + 1 > € Trans M . It follows by definition of reachability that q fc + 1 is 
reachable. 

Basis: Let q be an arbitrary element of {q € lnit M : W/ (q) « State x (0) for all / € /}. Note 
that this set is nonempty since it is a cartesian product of nonempty sets. Clearly q € 
Inv and vfaj = State x (0) for all /' € /. 

Induction: Suppose, for some k € Jf, that q k has been defined so that q k € Inv and w ( (q A ) 
= State x (t k ) for all i G /. Since X, is a computation for M r for each / G /, we know that 
« ( .(e A ) is enabled for M. in state v,(q k ), for each / G /. Since q k is reachable for M, the 
maximality condition implies that a{e k ) is enabled for M abs in state v^Jq,). Hence 
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[q € Q M : <q k , e k , q> € Trans M and v^q) = State x (t k + .,) for all / € /} is nonempty. Let q k + 1 
be an arbitrary element of this set. I 

The Correctness Theorem is an easy consequence of the preceding lemma. 

Theorem 3.9 (Correctness Theorem) - If the maximally and validity conditions hold for 
an implementation, then the implementation is correct. 

Proof - Suppose <5, S abs , <S ( > /€ ,> is an implementation, where S^ = <W abs , V abs > and 
that S. = </Lf. , Vj> for each / € / are state-transition specifications. Suppose that the 
maximality and validity conditions hold. Let M be the composite machine. Suppose that 
x € Obs<£) is such that S,(x) € 0{S) for all / € /. By Lemma 3.1 , it suffices to show that 
o(x) € 0(S abs ). Since fi,(x) € 0(S,) for each /' € /, we know that for each / € / there is a 
computation X, € V,, such that Obs x = «.(x). Since the collection X_ is x-coherent, by 
Lemma 3.8 there exists a computation X for the composite machine M, such that Obs x 
= x and such that X w = X, for all / € /. Using the validity condition, we then conclude 
that X< abs > € V^. It follows that a(x) = a(Obs x ) € OfS^), as required. I 

3.6 Possibilities Mappings 

In this section we show that the Correctness Theorem is a natural generalization of 
the "possibilities mapping" proof technique proposed by Lynch [Lynch83] and Goree 
[Goree81]. 

Lynch and Goree define a possibilities mapping to be a function that assigns a set 
of abstract module machine states to each vector of states for the component module 
machines, in such a way that the initial state set and state-transition relation are 
preserved. The fact that each vector of component module states is mapped to a set of 
abstract states, rather than to a single abstract state, means that possibilities mappings 
are a generalization of the usual notions of simulation or machine homomorphism. 
Intuitively, the value of the simulation mapping on a vector of component states is the 
set of "possible" abstract states that correspond to the given component states -- 
hence the name "possibilities mapping." 

Lynch and Goree's proof technique can be stated as follows: "If there exists a 
possibilities mapping for an implementation, then the implementation is correct." 
Interpreted in the framework of this thesis, Lynch and Goree's technique applies only to 
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implementations that involve state-transition specifications <M, V> for which V = 
Comp(Af). For such implementations, the validity condition required by the Correctness 
Theorem is vacuous. Theorem 3.10 below shows that the existence of a possibilities 
mapping is equivalent to the maximality condition required by the Correctness Theorem, 
and thus the Correctness Theorem includes Lynch and Goree's proof technique as a 
special case. 

To define the notion of a possibilities mapping, suppose <J, S abs , <S / > ye/ > is an 
implementation. Suppose S ab8 = <M aba , v^J and S, * <M n V?, for each / € /. Let M be 
the composite machine. 

Definition - A possibilities mapping for the implementation <5, S abs , <S / > /€/ > is a function 
t: ri /€/ ®m ~* ^m )» witn tne following properties: 

r flDS 

(1 ) lnit M C f(<q,> /€/ ) whenever q, € lnit M for all / € /. 

(2) For til q € M , if » abs (q) € /(< W/ (q)> /e/ ),'then: 

(a) Whenever r € Q M and e € E M are such that <q, e, r> € Trans w , then w^JLr) 
€ f«7r ; (r)> /£; ). 

(b) For all e € E u , if 8,(0) is enabled in state v f (q) for each / € /, then «(e) is 
enabled for M ab8 in state w^q). I 

Theorem 3.10 • Suppose that <3, S abs , <$,> /€ ,> is an implementation, where S abs and S s 
for each / € / are state-transition specifications. Then the following are equivalent: 

(1 ) There exists a possibilities mapping for <3, S ttM , £ >. 

(2) The maximality condition holds for O, S^, S >. 

Proof - Suppose that S ab8 = <M abs , V ab8 >, and that S, = Of,, V,>, for each / € /. Let M be 
the composite machine for the implementation <5, S^, S>. 

(1 ) = > (2): Suppose that / is a possibilities mapping for 5, S abs and £ . Define 

Inv = {q € M : ir abs (g) € /(<w,(q» /€/ )}. 
Condition (1) in the definition of a possibilities mapping implies that lnit M C Inv. 
Condition (2)(a) in the definition of a possibilities mapping implies that Inv is inductive, 
and hence by Lemma 3.2 contains all states reachable for M. The maximality condition 
now follows from condition (2)(b) in the definition of a possibilities mapping. 

(2) * > (1): Conversely, suppose that the maximality condition holds. Define f: n /€/ Q, -» 
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°abs as fo,,ows: '(^/e;) is the set of a " ^abs € °abs such that there exists a reachable 
state q for Af with «r abs (q) = q abs and w,(q) = q. for all /' € /. We claim that / is a 
possibilities mapping. 

Condition (1) in the definition of a possibilities mapping holds, since given <Q / > /C/ € 
n /e/ '"'V- then everv ^abs € ,nit M vields a state <( W **!?£? that is in ,nit M and h ence 

' 80S 

is reachable for M. 

To show that condition (2) holds, suppose that q is a state of M such that w abs (q) € 
'(<w,(9)>, e/ )- Then q is reachable for M by definition of /. To see that (2)(a) holds, note 
that if <q, e, r> € Trans w , then r is reachable by definition of reachability, and hence 
w abs^ € '(^fW^,)' Tne maximality condition implies that condition (2)(b) holds. I 

3.7 Rely-/Guarantee-Conditions 

In this section we will see how state-transition specifications whose sets of valid 
computations are defined by rely-Zguarantee-conditions can be used to perform the 
validity part of a proof of correctness. The principle of rely /guarantee conditions 
states that the set of valid computations V in a state-transition specification S = <M, V> 
should be defined in the form: "Rely implies Guar," where Rely expresses the properties 
that the module being specified relies on its envirbnment to provide, and Guar 
expresses the properties that the module guarantees to provide in return. 

For the synchronizer module, we wish the validity conditions to capture the idea 
that every user's request should eventually result in a response, if possible. The tricky 
part is the precise formulation of the "if possible" condition. Clearly if some user goes 
into the running state and remains in that state forever, then it will never be possible to 
allow any other user in the trying state to go to the running state, without violating the 
mutual exclusion property. This condition can be stated in rely- /guarantee-condition 
form as follows: "If every user process obeys the requirement that, once in the running 
state, it will eventually leave the running state, then the synchronizer module guarantees 
that every user in the trying state will eventually leave the trying state (and hence 
advance to the running state.)" 

We have two results, Lemma 3.11 and Lemma 3.12 below, that describe 
techniques for using rely- /guarantee-condition specifications in proofs of correctness. 
In both of these techniques, we are required to prove: 
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(•) Each component module's rely-condition is implied by the conjunction of the 

abstract module's rely-condition and the guarantee-conditions for some subset of the 
component modules. 

Although the exact form taken by condition (•) is different for the two techniques, a 
proof by either of the techniques is simplest when the rely- and guarantee-conditions for 
the component modules are chosen so that the truth of condition (*) is obvious. Thus, 
rely- and guarantee-conditions serve to "cut" the interdependence of modules on each 
other, analogously to the way in which a loop invariant cuts the dependence of one 
iteration of a loop on the previous iteration. This observation is strong motivation for the 
suggestion that module specifications ought not to be derived in isolation, but rather 
with a proof of correctness in mind in which those specifications are used. 

A correctness proof that makes use of Lemma 3.11 or Lemma 3.12 is rather 
different from one in which eventuality conditions (such as termination) are verified by 
the well-founded set techniques of [Floyd67, Keller76] and others. Proofs by the latter 
techniques tend to take the form of reasoning about the structure of a computation, 
whereas proofs by I emma 3.11 and Lemma 3.12 tend to be arguments based on the 
communication structure of the modules in the system. Experience gained from the 
examples presented in this thesis suggests that arguments based on communication 
structure are simpler and more natural. 

The use of rely- and guarantee-conditions has been proposed for safety 
specifications in [Jones83]. Independently of this thesis, Barringer and Kuiper 
[Barringer83] have proposed the use of liveness specifications that are partitioned into 
an "environment part," which captures assumptions made about the environment, and 
a "component part," which captures commitments made by the module being specified. 
Jones, as well as Barringer and Kuiper, exploit the rely-/guarantee-condition structure 
of specifications by defining inference rules for process composition that seem closely 
related to Lemma 3.1 1 . Barringer and Kuiper's environment/component division seems 
essentially the same as the rely/guarantee division used in this thesis, except that 
Barringer and Kuiper apply the environment/component division to state-transition 
properties, as well as liveness properties. 

Misra and Chandy [Misra81] have also used a kind of rely /guarantee distinction to 
develop proof techniques for safety properties. In that paper, a process h is specified by 
an assertion of the form r\h\s, where r and 5 are predicates on finite sequences (called 
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traces) of communication events. Such an assertion is interpreted as: "The predicate s 
holds of the empty trace, and for all traces t that can be produced by process n, if r 
holds for all proper prefixes of t, then s holds for all prefixes (both proper and improper) 
of f. The predicates r and s can be thought of as roughly analogous to rely- and 
guarantee-conditions, respectively, although the former are properties of finite prefixes 
of traces rather than properties of infinite computations. Misra and Chandy's proof 
technique is a "Theorem of Hierarchy," which gives conditions under which 
specifications of a collection of components can be used to infer a specification of the 
network formed by interconnecting the components. Their proof technique can be 
stated as follows: To show that the specification /?0|W|SO for the network H is a 
consequence of the specifications rjihjis l (i € I) for the components, it suffices to show 
that: 

(1) S implies SO, 

(2) RO and S implies R, 

where R and S denote the conjunction of the r t and s,, respectively. These conditions 
are syntactically similar to the conditions (1) and (2) of Lemma 3.11, although their 
meaning is quite different. The proof of Misra and Chandy's Theorem of Hierarchy is by 
induction on computation prefixes, whereas the proof of Lemma 3.1 1 is by structural 
induction using a well-founded dependency relation. 

In [Misra82], the techniques of [Misra81] are extended to encompass a weak form 
of liveness specification in which an additional predicate q is used to state conditions 
under which a process trace is guaranteed to be extended. The Theorem of Hierarchy 
is augmented with additional conditions to permit its application to these more general 
specifications. The additional conditions do not appear to relate in a simple way to any 
conditions used in this thesis. 

To state Lemma 3.11 and Lemma 3.12, the following notation is convenient: If R 
and G are subsets of a universe U, then define R-* U G (read R implies G in U) to be the 
subset (17 - R) U G of U. In applications of Lemma 3.1 1 and Lemma 3.12, the set U will 
be the set Comp(M) of computations of a machine M, and R and G will be the sets of 
computations of M that satisfy rely-conditions and guarantee-conditions, respectively. 

Lemma 3.1 1 below says that to prove that the validity condition holds, it suffices to 
prove: 

(1) The abstract module's guarantee condition is implied by the conjunction of 
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the guarantee conditions for the component modules. 

(2) There exists a well-founded partial ordering (a "depends on" relation) of 
the component modules in the system, such that each component module's 
rely-condition is implied by the conjunction of the abstract module's rely-condition and 
the guarantee-conditions for the modules on which the component depends. 

Lemma 3.1 1 - (Rely/Guarantee Technique I) - Suppose U is a set and that /? abs , G abs , 
and R jt G ( . for each / € / are subsets of U. Suppose V abs * R Bba -»„ G abs and V, = 
R, -* u G n for each / € /. Suppose 

< 1 > n ,e, Grabs' 

(2) There exists a well-founded partial order < on / such that for all / € /, 

Thenn /€/ v ; cv ab8 . 

Proof - Suppose X € /? abs n (n /e/ V,). Suppose further, to obtain a contradiction, that X 
€ G ab8 . Then by hypothesis (1 ) we know that X € G ; for some / € /. 

Since X i G. , and since X € V, by assumption, it must be the case that X € R. . By 
'o 'o 'o 

hypothesis (2) and the assumption that X € A? aba , there exists /, < / such that X £ G, . 

Repeating this argument yields an infinite descending sequence i Q > 1^ > ... , in 

contradiction with the well-foundedness of <. I 

An example of the use of Lemma 3.1 1 can be found in the proof of correctness of 
the transmission module implementation in Appendix II. 

The existence of the "depends on" relation required to satisfy hypothesis (2) of 
Lemma 3.11 is a rather stringent condition. In some cases, for example the 
synchronizer implementation, all of the component modules in the system are 
symmetric in their relationship to each other, and it is hard to see how a suitable 
dependency relation might be found. Lemma 3.12 below shows that an alternative 
"acyclicity" condition can be used, in case the component module rely- and 
guarantee-conditions can be factored in a certain way. Specifically, Lemma 3.12 
assumes that the rely-condition for module / can be expressed as the conjunction of 
what module / relies on the external environment and on each component module / to 
provide, and that the guarantee-condition for module / can be expressed as the 
conjunction of what module / guarantees to the external environment and to each 
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component module/'. 

In Lemma 3.12 below, one should think of fl abs , G abs as the rely- and 
guarantee-conditions for the abstract module, and of R p G, as the rely- and 
guarantee-conditions for component module /. The hypotheses of Lemma 3.12 require 
us to find {RG.,: i, j € / + {abs}}. (RG stands for "rely/guarantee.") Intuitively, if /', / € /, 
then RG.. expresses what module /' guarantees to module /, and also what module /' 
relies on module / to provide. RG atisJ expresses what the external environment of the 
entire system guarantees to component module /, and also what module / relies on the 
external environment to provide. rtG /ab8 expresses what component module / 
guarantees to the external environment, and also what the external environment relies 
on module / to provide. 

Condition (1)(a) and (1)(b) in Lemma 3.12 state, intuitively, that the abstract 
module's rely-condition implies what each of the component modules rely on the 
external environment to provide, and that the abstract module's guarantee condition is 
implied by the conjunction of what each of the component modules guarantees to 
provide to the external environment. Condition (2)(a) states that each component 
module's rely-condition is implied by the conjunction of what that component relies on 
the external environment to provide and on what that component relies on the 
component modules in the system to provide. Condition (2)(b) states that the 
guarantee-condition for component module / implies what module / guarantees to the 
external environment and what module /' guarantees to each of the component modules 
in the system. Condition (3) in Lemma 3.12 is an acyclicity condition, which states that 
there can be no unbroken cyclic dependency between component modules. 

If / is a set, then define a cycle of / to be a nonempty subset of / X / of the form: 
{</ , /,>, <l v i 2 > <J n _ v /'„>}, such that /„ = / . 

Lemma 3.1 2 (Rely/Guarantee Technique II) - Let / be a finite index set. Suppose that 
U is a set and that /? abs , G abs , and /?;, G. for each / € / are subsets of U. Suppose V abs = 
fl abs -> u G abs and V i = R t -* u G jt for each / € /. If there exists, for each /, / € / + {abs}, a 
set RG tj C U such that (1)-(3) below hold, then n /e/ V. Q V^. 

(D(a) R^cn^RG^j. 
(b) n /e/ flG, abs CG ab8 . 

(2)(a) n /e/+{abs} ftG / ,Cfl.,forall;e/. 
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(b) G ( .cn y€;+{ate} f?G,,,forall/€/. 
(3) Whenever {</„, /,>, <i v i 2 > <i„_ v '„>} is a cycle of /, then 

* =0 '*•'* + 1 
Proof • Suppose (1)-(3). Suppose further, to obtain a contradiction, that there exists X 
€ u n R abs n (n »e; V sucn that x * G abs- We Per 10 '"'" an inductive construction to 

obtain a "cycle {<i m , / m + 1 > </„, /„ +1 » of / such that X ( Ujft,, «G Vfc+1 - ™s 

contradicts hypothesis (3). 

As the induction hypothesis at stage k of the construction, we assume that 
/ 1§ i 2 i k have been constructed so that X I /?, , and that X € U*; 1 , RG ljJj+ 1 - 

eas/s: From (1)(a) and the assumption that X € f? abs , we know that X C AG^. for all / € /. 
Since X € G^, by (1)(b) we know that X I RG, ^ for some /, € /. By (2)(b) we know 
that X I G, , and from the assumption that X € V, , we conclude X € R,^. 

Induction: Assume the induction hypothesis holds for some k £ 1. By (2)(a) we know 
thatXfcflG. , for some /_.,€/. \ti.. mi for some m with 1 < m < k, then we have 

'<r A + 1 

obtained the desired cycle and the construction terminates. Otherwise, by (2)(b) we 

know that X t G, , and from the assumption that X € V, , we conclude that X t 

'a + 1 ** 1 

R. . This establishes the induction hypothesis for k + 1 . 

Vc + 1 

Since the set / is finite by hypothesis, we cannot extend the sequence /,, / 2 , ... , i k 
indefinitely without creating a cycle. I 

Examples of the use of Lemma 3.1 2 can be found in the proof of correctness of the 
synchronizer implementation in Chapter 4, and in the proof of correctness of the 
resource manager implementation in Appendix II. 
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4. The Synchronizer Implementation 

In this chapter, the theory developed in Chapter 3 is applied to obtain complete 
specifications and a proof of correctness for the synchronizer example. In Section 4.1 
we review the synchronizer module specification which has already been developed. It 
is shown how the set of valid computations for this specification can be given a concise 
definition using the language of temporal logic. In Section 4.2, the synchronizer 
component module specification is presented. In Section 4.3, the definition of the 
synchronizer module implementation is reviewed. In Section 4.4, the Correctness 
Theorem is used to prove the correctness of the synchronizer implementation. 

4.1 Notation 

This section introduces the notation we will use to express state-transition 
specifications, and in particular, the temporal logic notation we use to define the sets of 
valid computations. We use this notation in this chapter in a highly informal fashion, 
and do not concern ourselves with precise syntax and semantics. The reader who is 
interested in a careful treatment of the notation we use is referred to Appendix I. 

To define a state-transition specification S, we first define the interface E s and 
state set Q s of the machine M $ . As discussed in detail in Appendix I, we regard these 
two sets as two distinguished sorts Events and States in a many-sorted algebra A $ . We 
associate a first-order language l(S) with the algebra A s in the usual way. The 
language 1{S) is used to define the initial state set lnit s and the state-transition relation 
Trans s of the machine M $ . In this chapter, we often use constructions that are not part 
of a first-order language. Appendix I shows now the use of these constructions can be 
justified. 

From the first-order language l(S), we obtain a temporal language 3(S) by 
augmenting l(S) with the temporal operators a (read "henceforth") and O (read 
"eventually"), which are applied to formulas to obtain new formulas. In addition, three 
new atomic terms are added to the language: Now and After, which behave 
syntactically like constant symbols of sort States, and Occurs, which behaves like a 
constant symbol of sort Events. The meanings of the symbols Now, Occurs, and After 
depend upon the particular instant of time under consideration, and thus are altered by 
the action of temporal operators □ and O in a way that is detailed below. Intuitively, if 
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the particular instant of time under consideration is f, then Occurs denotes the event 
that occurs at time /, Now denotes the state at time t, and After denotes the state "just 
after" time f . 

The semantics of the temporal language associated with a specification S = 
<M, V> are captured by the binary relation N (read "satisfies"), which tells when a 
formula of the temporal language is satisfied by a particular history over E M and Q M . To 
assert that the history X satisfies a particular temporal formula 9, we write X h= 9. 
Satisfaction is defined informally as follows: If 9 is a formula that contains no 
occurrences of temporal operators, then X h- 9 iff v holds in the usual sense of 
first-order logic, with the symbols Now, Occurs, and After interpreted as State x (0), 
Obs x (0), and State x (0 + ), respectively. If 9 is a formula of the form □*, then X N 9 iff 
suffix (X) 1= «/< for all t € [0, 00). If <p is of the form Of, then X N= 9 iff suffix,(X) 1= * for 
some t € [0, 00). Note that the semantics we use are essentially the "linear time" 
semantics of [Lamport80], and hence the O operator is equivalent to the compound 
operator ->□-«. 

We say that a formula 9 is a consequence of a set of formulas *, written * *= 9, if 
X N 9 whenever X N f for all * € *. A formula 9 is valid, written N= 9, if it is a 
consequence of the null set of formulas. 

The temporal language 9{S) of a specification S = <M S , V s > contains an important 
sentence to which we shall refer extensively. This is the sentence 

Comp s 3= lnit s (Now) a DTrans s (Now, Occurs, After). 
Intuitively, X N Comp s iff X is a computation for the machine M s . 

4.2 Specification of the Synchronizer Module 

In this section, we review the state-transition specification S^ = <M SM , V 8 ^ of 
the synchronizer module, which has already been developed in Chapter 3. 

Let Proc be a finite set of user processes. 

Interface: 

E^ = {X} U {try p , run p , rest p : p € Proc}. 
In anticipation of Chapter 5, we classify each event in the synchronizer module interface 
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as either an input event, an output event, or both (the null event X is the only event that 
is both an input and an output event). 

In 5 * 4 = {X} U {try p , rest p : p € Proc} 

Out 5 ** = {X} U {run p :p € Proc}. 
Although our theoretical framework so far draws no formal distinction between input 
and output, in Chapter 5 such a distinction is introduced to obtain a useful test for 
consistency of liveness specifications. Input events should be thought of intuitively as 
stimuli that are applied to a module by its environment, and output events as responses 
applied by a module to its environment. A module does not have the capability of 
regulating the application of input stimuli to it. 

Machine: 

The state set for the synchronizer module machine is defined by 
qSm = n p€Proc {trying, running, resting, error}. 
To ease later discussion, let us say that process p is resting (resp. trying, running, in 
error) in state q if q{p) * resting (resp. trying, running, error). 

The set of initial states for the synchronizer module machine is defined by 
InH 8 * 4 ■ {q € s * 4 : q(p) = resting for all p € Proc}. 

A step <q, e, r> is in the state-transition relation Trans*** for the synchronizer 
module machine iff either e = X and q * r, or one of the conditions (try), (run), or (rest) 
below is satisfied for some p € Proc. 

A try event for process p can occur at any time. If process p was previously resting then 
it advances to the trying state, otherwise to the error state. The states of all other 
processes are unaffected. 

(try) e ■ try p , and either 

q(p) = resting and r * Q[trying/p], or 

q{p) * resting and r ■ g[error/p]. 

A run event for process p can occur only if process p is trying, and no other processes 
are currently running. Process p advances to the running state, and the states of all 
other processes are unaffected. 

(run) e = run p , g(p) = trying, g(p *) * running for all p ' € Proc - (p), 
and r = g[running/p]. 
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A rest event for process p can occur at any time. If process p was previously running, 
then it advances to the resting state, otherwise to the error state. The states of all other 
processes are unaffected. 

(rest) e = rest p , and either 

q{p) = running and r = g[resting/p], or 

q(p) * running and r = q[error/p]. 

Validity Conditions: 

We wish the validity condition for the synchronizer module to capture the idea that 

every user's request should eventually result in a response, if possible. This condition 

can be stated in the rely- /guarantee-condition form as follows: "If every user process 

obeys the requirement that, once in the running state, it will eventually leave the running 

state, then the synchronizer module guarantees that every user in the trying state will 

eventually leave the trying state (and hence advance to the running state)." We can 

express this condition concisely as a temporal sentence. 

Valid^ s Rely^ -* Guar^ 

where 

ReiySM E D(Vp€Proc)(Now(p) = running - 0(Now(p) * running)) 

Guar 5 ** = D(Vp€Proc)(Now(p) = trying - 0(Now(p) * trying)). 
4.3 Specification of the Synchronizer Component Module 

A synchronizer component module communicates with an associated user 
process via the try, run, and rest events, with its neighboring synchronizer component 
module in the clockwise direction via fo*en_ouf and requestjn events, and with its 
neighboring synchronizer component module in the counterclockwise direction via 
token Jn and request jout events. The conceptual state of the module contains a count 
of the number of tokens the module possesses, plus information concerning the state of 
the associated user process. The synchronizer component module can allow the user 
process to enter the running state only if it possesses a token, and must retain a token 
throughout the entire period during which the user is in the running state. We would 
like the synchronizer component module to be "fair" in the sense it eventually grants 
each user request, if possible, and eventually responds to each request for the token by 
its clockwise neighbor in the ring, if possible. 
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The specification of the synchronizer component module is parameterized by the 
number of tokens it possesses in the initial state. Thus the specification presented 
below actually is a specification schema that represents a family {SC fc : k € JO of related 
specifications, where SC fc is the specification for the synchronizer component module 
with k tokens in the initial state. The only place the initial number of tokens appears in 
the specification is in the definition of the initial state set. 

Interface: 

The first task in the construction of the synchronizer component module 
specification is the description of its interface. 

E 80 = {X, try, run, rest, tokenjn, token.out, requesUn, request_out}. 
The sets of input and output events are defined by: 

In 80 = {X, try, rest, tokenjn, requesUn} 

Out 80 = {X, run, token_out, requesLout}. 

Machine: 

A state for the synchronizer component module contains a "token" component, 
whose value represents the number of tokens the module possesses, and a "ustate" 
component, which tells what state the synchronizer component module thinks the user 
process is in. 

O sc = token: JfX ustate: {trying, running, resting, error}. 
The "tags" token and ustate are used as selectors; if q € O 80 , then o(token) denotes the 
token component of q and g(ustate) denotes the ustate component. 

In an initial state the synchronizer component module SC^ has k tokens and the 
user process is resting. 

Init 80 * = {q € Q 80 : o(token) = k Aq(ustate) = resting}. 

A step <q, e, r> is in the state-transition relation Trans 9 ^ for the synchronizer 
component module machine iff either e = X and q = r, or one of the conditions (try), 
(run), or (rest), (tokenjn), (token.out), (requesUn), (request_out) below is satisfied: 

A try event can occur at any time. If the user process was previously resting, then it 
advances to the trying state, otherwise to the error state, 
(try) e = try and either 
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q(ustate) = resting and r = q[trying/ustate], or 
q(ustate) * resting and r = q[error/ustate]. 



A run event can occur only if the user process is trying and the synchronizer component 
module currently possesses a token. The user process advances to the running state, 
(run) e = run, q(ustate) = trying, q(token) * 0, and r = g[running/ustate]. 

A rest event can occur at any time. If the user process was previously running, then it 

advances to the trying state, otherwise to the error state, 
(rest) e = rest and either 

q(ustate) = running and r = q[resting/ustate], or 
q(ustate) * running and r = q[error/ustate]. 

A token Jn event can occur at any time, and causes the number of tokens possessed by 
the synchronizer component module to be increased by one. 

(tokenjn) e = token_in and r = q[q(token) + 1 /token] 

A token jout event can occur only if the user process is currently not running, and the 
synchronizer component module possesses at least one token. The number of tokens 
possessed is decremented. 

(token.out) e = token.out, q(ustate) * running, q(token) * 0, and 

r = q[q(token)-1 /token] 

A request Jn event can occur at any time, and has no direct effect on the state. The way 
in which a requesUn event induces the synchronizer component module to eventually 
respond with a token_out event is captured by the validity conditions. 
(requesUn) e = requesUn and r « q 

A request jout event can occur only if the synchronizer component module currently 
does not possess a token. Occurrence of such an event has no effect on the state. 
(request_out) e = request_out, q(token) = 0, and r * q 

Validity Conditions: 
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We would like the synchronizer component module validity conditions to capture 
the following two ideas: 

(1) A synchronizer component module always eventually satisfies a user's 
request, if possible. 

(2) A synchronizer component module always responds to requests for the 
token issued by its clockwise neighbor, if possible. 

We can state this in rely- /guarantee-condition form as foHows: If all requests issued by 
the synchronizer component module to its counterclockwise neighbor are eventually 
granted, and the user process never remains forever in the running state, then all user 
requests and all requests for the token from the clockwise neighbor, will eventually be 
granted. Formally, 

Valid sc s Rely 5 * - Guar 80 , 
where 

RelySc s n(Now(ustate) = running -♦ 0(Now(ustate) *■ running)) a 
□(Occurs = request_out -* 0(Now(token) * 0)) 

Guar 80 == □(Now(ustate) = trying -► 0(Now(ustate) * trying)) a 
□{Occurs = requesUn -* 0(Occurs * token_out)) 

4.3.1 The Synchronizer Implementation 

/ 

To be able to describe and reason about the synchronizer implementation we must 
formalize the idea that the set Proc is a "ring-structured set of processes with a 
distinguished process." We assume that the set Proc is the set of integers modulo N for 
some N, and that zero is a distinguished process, which will be the process that initially 
possesses the token. 

We first define the synchronizer interconnection 

The abstract interface D SM] is the synchronizer module interface E SM , and the pth 
component interface F 8 /*' is the synchronizer component module interface E 80 . 

The composite interface for the synchronizer module implementation is defined 
by: 

E SM] = {X} + {try p , run p , rest p , token p , request p : p € Proc}. 

In 81 * 1 = {X} + {try p , rest p : p € Proc} 

Out 3 * 1 = {X} + {run p , token p , request p : p € Proc}. 
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The try p , run , and rest events in the composite interface correspond under the 
decomposition map to try, run, and rest events for synchronizer component module p, 
and under the abstraction map to try p , run , and rest events for the synchronizer 
module. A token p event represents the transmission of a token from synchronizer 
component module p to synchronizer component module p + 1 (i.e. in the clockwise 
direction around the ring), and a "request" event represents the transmission of a 
request from synchronizer component module p to synchronizer component module 
p-1 (i.e. in the counterclockwise direction). We capture this information formally by 
defining the abstraction map a SMi and decomposition map £ SMI . 
a^'te) m e, if e € {try p) run p , rest p : p € Proc}, 

= X, if e € {token pl request^: p € Proc} U {X}. 

«f"(e) = try, if e . try p 

* run, if© « run 

= rest, if e = rest 

= tokenjn, ife = token , 

= token_out, if e = token 

» requesUn, if e = request 1 

= requesLout, if e = request 

= X, otherwise. 

To complete the description of the synchronizer implementation <5 SMI , SjJJ £ **>. 
we must define the specifications SjJJ and S** for each p € Proc. The specification 
S|JJ is the synchronizer module specification S 8 **. The specification sjjj is the 
specification S^i of the synchronizer component module with one initial token, and for 
all p € Proc - {zero), S^ 1 is the specification S^o of the synchronizer component 
module with no initial tokens. 

4.4 Correctness of the Synchronizer Implementation 

In this section, we use the techniques of Chapter 3 to show the correctness of the 
synchronizer implementation. Most of the proof consists of straightforward case 
analyses. The interesting content of the proof is contained in the use of Lemma 3.12 to 
prove that the validity condition holds. 
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4.4.1 Implementation Invariant 

To prove the correctness of the synchronizer module implementation, we first 
need to find an implementation invariant that provides enough information about the 
reachable states of the composite machine so that we can prove the maximality 
condition. The implementation invariant will also be useful in the proof that the validity 
condition holds, and so in this section we define an implementation invariant that is 
strong enough for both the maximality and validity proofs. 

For a set Inv to be an implementation invariant for an implementation means that it 
is inductive for the composite machine for the implementation. Formally, if M is the 
composite machine and £ the composite interface, we must show: 
(Basis) (Vq£Q M )(q € lnit M -► q € Inv)) 

(Induction) (Vq,r€Q M , e € £)(<q, e, r> € Trans w -► {q € Inv - r € Inv)). 

It is generally convenient to define an implementation invariant Inv by a predicate 
lnv(g) = Rep(g) a Abs(g), 
where Rep is called the representation invariant and Abs is called the abstraction 
relation. A representation invariant describes a relationship that must hold at all times 
between the states of component modules in an implementation. Representation 
invariants serve roughly the same purpose here as what is called the "data type 
invariant" in the literature on abstract data types [e.g. Jones81, Jones83]. An 
abstraction relation describes the correspondence between the states of the 
component modules and the state of the abstract module. The abstraction relation 
plays the same role here as the "retrieve functions" of [Jones81], and the 
"representation functions" of [Hoare72]. 

The implementation invariant /nv 8 ™ for the synchronizer implementation is defined 
as follows: 

Inv^'fo) s Rep^'fo) a Abs^g), 
The abstraction relation Abs^ 1 holds of state q iff in state q, the abstract synchronizer 
module's view of the state of the pth user process is identical to the pth synchronizer 
component module's view, for each p in Proc. Stated another way, the abstract 
synchronizer module state corresponding to a given collection of synchronizer 
component module states is obtained by throwing away all information, except for the 
ustate component, in the states of the component modules. Formally, 
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Abs SM1 ( Q ) . A p£Proc (q abs (p) = Q p (ustate)), 
where we have used the notations q abs , q p as abbreviations for ir abs (g), * p (q), 
respectively. 

The representation invariant Rep SMI is defined by: 

Rep^'to) = Mutex(q) a Token(q). 
Mutex(g) states that if a user process is in the running state, then the corresponding 
synchronizer component module must possess a token. Formally, 

Mutex(g) s A p€Proc (g p (ustate) = running -♦ g p (token) * 0). 
Token(g) asserts that the total number of tokens in the system at any time is precisely 
one. 

Token(q) = 2 p£Proc g p (token) = 1. 

The proof that Inv^'fa) is in fact an implementation invariant for the synchronizer 
implementation is a straightforward induction. 

Basis: It follows directly from the initial state sets that if Init^'fa) holds, then 
g abs (p) = resting for all p € Proc 

q zer0 = <token: 1, ustate: resting> 

Q p = <token: 0, ustate: resting> for all p € Proc-{zero}. 

It is easily checked that these three conditions imply that Abs^'ta), Mutex(q), and 
Token(q) all hold. We conclude that Inv^g) holds for all q € lnit SM1 , as required. 

Induction: We must show that for all <q, e, r> € Trans^', if Inv^g) holds then Inv^'f/) 
does, too. Suppose that <g, e, r> € Trans 8 **' and Invito) holds. 

First of all, note that if e = X, then q = r and hence Inv^'f/) follows trivially from 
Inv^'fa). We therefore assume in what follows that e * X. We consider separately the 
proofs of Abs^V). Mutex(r), and Token(r). 



To prove that Abs^V) holds, there are two cases: (1) e € {token p , request p : p € 
Proc}; and (2) e € {try p , run p , rest p : p € Proc}. Case (1) is disposed of quickly by noting 
that if e = token p , or e = request p for some p € Proc, then ^(p *) = q^J^P *) and 
r p .(ustate) = g p .(ustate) for all p ' € Proc. Thus in this case Abs^V) follows directly 
from Abs^'fa). Case (2) is handled by a straightforward enumeration of the cases: e = 
try , e = run , e = rest , and verifying that in each case, the occurrence of e results in 
identical values for r abs (p ') and r p .(ustate), for each p ' € Proc. 
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We now consider the proof that Mutex(r) holds. Suppose not, then it must be the 
case that r p (ustate) = running and r (token) = for some p € Proc. By a case analysis 
on e it is straightforward to check that the only way this can happen is if either g (ustate) 
= running and e = token , or g (token) = and e = run . Examination of the 
specification of the synchronizer component module shows that it is impossible for a 
token p event to occur if g p (ustate) = running, and also for a run event to occur if 
g p (token) = 0. 

Finally, we wish to show that Token(r) holds. A case analysis on e shows that the 
only events that affect the number of tokens in the system are those of the form token 
for some p € Proc. Examination of the specifications shows that, when such an event 
occurs, r p (token) = g p (token) - 1, r p+1 (token) * g p + 1 (token) + 1, and r p .(token) = 
q p .(token) for all p ' € Proc - {p, p + 1 }. Thus 2 p - €Pr0C r p .(token) = 2 p . £PfOC q p .(token), 
and hence Token(r) holds. 

4.4.2 Proof of Maximally 

We must show that for all q € O^ 1 and e € E^ 1 , if /nv^'fo) holds and fijf^e) is 
enabled in state q p for all p € Proc, then ^'(e) is enabled in state g abs . 

Suppose /nv^'fa) holds and that S^ie) is enabled in state q p for all p € Proc. 
There are two cases: (1) e = run for some p € Proc; and (2) e is not of this form. 
Examination of the synchronizer module specifications shows that case (2) is trivial, 
since a(e) is enabled in any state unless e = run for some p € Proc. 

Now consider case (1 ). Since fij^e) is enabled in state q , from the synchronizer 
component module specification we know that 

(A) g p (ustate) = trying and g p (token) # 0. 
The assumption that Inv^'fa) holds implies that Token(q), Mutex(g), and Abs^'fa) all 
hold. From (A) and Abs^'fa) we infer that q abs (p) ■ trying. From (A) and Token(g) we 
know that g p .(token) = for all p ' € Proc-{p}. From this and Mutex(g) we infer that 
g p .(ustate) * running for all p ' € Proc-{p}. From this and Abs^g), we conclude that 
Q aba {p "i * running for all p ' € Proc-{p}. We have shown that 

( B > 9abs<P) = trv 'n9 A ( A p €Proc-{p} W" *> * running), 

holds. Examination of the synchronizer module specifications shows that (B) implies 
that a^'te) is enabled in state g ab3 , as desired. 
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4.4.3 Proof of Validity 

To express the proof that the validity condition holds for the synchronizer 
implementation, we associate a temporal language StS^ 1 ) with the composite 
specification S 8 * 41 = <M SM \ V 81 ^ in the same way as temporal languages were 
associated with the synchronizer module and synchronizer component module 
specifications. In addition, we must have some way of taking the temporal sentences, 
each expressed in its own temporal language, that define the sets of valid computations 
for the synchronizer module and synchronizer component module specifications, and 
"lifting" them to the common language ^S^ 1 ). This can be accomplished by a simple 
syntactic translation, which we now define. 

To each formula q> of ^S 8 * 4 ) we associate a corresponding "lifted" version I<pJ ftbs 
of g(S SMI ), by replacing each occurrence of the symbol Now by the term Now abs , each 
occurrence of After by the term After abs , and each occurrence of Occurs by the term 
a SM'(Occurs). Similarly, to each formula 9 of <3[S^) and each p € Proc, we associate a 
corresponding formula l<p} p € ^S^ 1 ), by replacing each occurrence of Now by Now,, 
each occurrence of After by After,, and each occurrence of Occurs by ^'(Occurs). 

The precise relationship between a formula and its lifted version is captured by 
Lemma 1.2 in Appendix I. Informally, if «p € ^S^), then a history X for the composite 
machine M^ satisfies the formula |<pl abs € 9^') iff the canonical projection X (abs) of X 
satisfies the formula <p. Similarly, if 9 € 91S 80 ), then a history X for M**" satisfies M p W 
X w satisfies 9. An analogous result is stated in [Wolper82], where the process of 
"lifting" specifications of individual processes to obtain specifications of a system of 
processes is called "relativization." 

In the proof that the validity condition holds for the synchronizer implementation, 
we must have some way of making use of the information contained in the 
state-transition relation of the composite machine. We do this by using the 
implementation invariant according to the following rule of inference: If Inv has been 
shown to be invariant, then 

Comp N Dlnv(Now) 
holds. This rule, whose validity follows from Corollary 3.7, will be used extensively in our 
correctness proofs. 



78 



To show that the validity condition holds for the synchronizer implementation, we 
must show that: 

Comp 8 ™ H A pGProc IValid sc J p - IValid SM ]| abs . 
In light of Lemma 3.12 it suffices to find, for each /, / € Proc + {abs}, a temporal 
sentence RG. such that conditions (SMI1)-(SMI3) below hold. 

(SMI1)(a) Comp^' N ffRely 8 ^ - A y€Proc RG abs , 

(SMI1)(b) Comp^' N A /€Pr0C RG /ab8 - IGuar^l^ 

(SMI2)(a) Comp^' N A y£Proc (A, ePf0C+{ab8} RQ y - ffRely^) 

(SMI2)(b) Comp^' N A /€Proc (ffGuar^l, - A y£Proc+{abs} RG„) 

(SMI3) Whenever {</' , /',>, <J V i^>, ... , </„_,, i n >) is a cycle of Proc, then 

Comp^ 1 N V"" 1 n RG, , . 
" =u V* + 1 

The sentences RG,, express what is relied/guaranteed between each pair of 

synchronizer component modules or between a synchronizer component module and 

the external environment of the entire system. The synchronizer component module 

specifications have been chosen in such a way that the sentences RG,. . can be obtained 

simply by "lifting" the synchronizer component module rely- /guarantee-conditions to 

the temporal language of the composite machine. The formal definitions are as follows: 

For all /',/€ Proc, t 

RG, abs = D(Now / .(ustate) = trying -► 0(Now / (ustate) * trying)) 

RG absJ s= D(Now y (ustate) = running -* 0(Now y (ustate) * running)) 
For all / € Proc, 

RG M ^. s DfSf^Occurs) = request_out -► O(Now,(t0ken) * 0)) 
For all /, / € Proc such that / + 1 * j, 

RG /V s true 

Next, we verify (SMI1)-(SMI3). Assume Comp SMI throughout the remainder of the 
proof. The interesting intuitive content of the validity proof is contained in the proof that 
(SMI3) holds. The remaining cases are practically automatic. 

Intuitively, hypothesis (SMI1)(a) says that the abstract module rely condition 
implies what each component module relies on the external environment to provide. 
Hypothesis (SMI1)(b) says that the conjunction of what each component module 
guarantees to the external environment implies the abstract module 
guarantee-condition. Formally, we must show: 
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(SMI1)(a) |Rely^fl abs - A peProc RG abs , 

(SMI1)(b) A peProc RG pabs - BGuar^^ 
We show (SMI1)(a), condition (SMI2)(b) is equally straightforward. From the 
synchronizer module specifications, we know that 

IRely^^^ = OA p€Proc (Now abs (p) = running - 0(Now abs (p) * running)) 
Suppose that iRely 9 ^]]^ holds. By the invariance of the abstraction relation Abs^', we 
infer 

□A p€Proc (Now p (ustate) = running -♦ 0(Now p (ustate) * running)). 
Interchanging the D and conjunction yields 

as desired. 

Intuitively, hypothesis (SMI2)(a) says that each component module's rely-condition 
is implied by the conjunction of what is guaranteed to it by the external environment and 
by each other component module. Hypothesis (SMI2)(b) says that each component 
module's guarantee-condition implies what the external environment and each other 
component module rely on it to provide. Formally, we must show: 
(SMI2)(a) A /€Proc + {abs) RG.^, - ffRely^, for all p € Proc 
(SMI2)(b) flGuar*^ _* A /€Proc +{abs} RG p ., for all p € Proc. 
To show condition (SMI2)(a) is completely straightforward. Let p € Proc be fixed. It 
suffices to show that RG^^ a RG^^ -* [[Rely 80 ^. By definition 

RG abSiP = D(Now p (ustate) = running -* 0(Now p (ustate) * running)) 
RG p-i,p - Q(Sp 3MI (Occurs) = request-out -♦ 0(Now p (token) * 0)). 
The conjunction of these two sentences is easily seen to be equivalent to IRely sc J by 
inspection of the synchronizer component module specifications. 

To show (SMI2)(b) is not completely trivial because of the fact that what 
component module p guarantees to module p + 1 is not exactly what module p + 1 relies 
on module p to provide. Specifically, module p guarantees always to eventually send 
the token in response to a request from module p + 1 . However, module p + 1 relies not 
on the eventual occurrence of a token Jn event, but rather on the eventual setting of the 
token component of its state to a nonzero value. The nontrivial portion of the proof is to 
use the state-transition relation for module p + 1 to show that occurrence of a token Jn 
event for that module implies the eventual setting of the token component of its state to 
a nonzero value. 
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Formally, to prove (SMI2)(b) it suffices to show that fGuar 80 ^ — RG pabs a 
RG„ „ i. since RG„ . s true by definition unless/ = abs or /' = p + 1 . By definition 

pip + 1 Prf 

RG p abs s D(Now p (ustate) = trying -> 0(Now p (ustate) * trying)) 

RG pj)+1 s D(« p ^' 1 (Occurs) = request_out -» 0(Now p+ /token) * 0)). 
By inspection of the synchronizer component module specifications, we have 

fGuar^Jp = D(Now p (ustate) = trying -» 0(Now p (ustate) * trying)) a 

□(^'(Occurs) = requesUn -+ O(«| MI (0ccurs) = token_out)). 
Assume IGuar 80 ]] . Then RG paba follows immediately from the first conjunct of 
fGuar 80 ]) . To show that the second conjunct of gGuar 80 ^ implies RG pj}+1 , note the 
definition of the state-transition relation for synchronizer component module p implies 
that 

□(S^'/Occurs) = tokenjn -+ 0(Now p+1 *0)). 
From the second conjunct of JGuar^L, using the definition of the decomposition map 
Sl smi , we obtain 

□(S^'/Occurs) = request_out -* OtS^'/Occurs) = tokenjn)). 
Combining the preceding two sentences and applying temporal reasoning shows 
RG p ^ + ,, as desired. 

The most interesting part of the proof is the proof that (SMI3) holds. To show 
(SMI3), we must show that 

Comp^' »« V"" 1 , RG. . 
holds for every cycle {</' , /,>, ... , <J n _ v i n >) from Proc. The only nontrivial case is the 
cycle {<zero, zero+1>, <zero+1, zero + 2>, ... , <zero + AM, zero>} that traverses the 
entire ring in the clockwise direction, since every other cycle from Proc contains a link 
</, j> for which RG yJ = true by definition. Suppose, to obtain a contradiction, that 
(SMI3) fails for this cycle. Then for all p € Proc, the sentence RGp.^ does not hold. 
This means that 

A p€Proc Ota^Occurs) = request.out a D(Now p (token) = 0)). 
That is, for each p € Proc, eventually a point is reached at which synchronizer 
component module p issues a request_out event, but never has the token after that 
point. This implies that 

A P €Proc OD(Now p (token) = 0). 
Since Proc is a finite set, it is valid to interchange the conjunction and O operator in the 
preceding formula, concluding that 

OA p€Proc n(Now p (token) - °>- 
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This asserts that there is some point after which no synchronizer component module 
ever possesses a token. This is a contradiction with the invariance of Token, which 
states that the total number of tokens in the system is always precisely one. I 
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5. Consistency of Specifications 

In Chapter 3 it is suggested that module specifications ought to be expressed in 
rely-/guarantee-condition form, and that the rely- and guarantee-conditions for the 
component modules in a system ought to be selected so that each component module 
guarantees precisely the conditions relied upon by its neighbors in the system. In 
Chapter 4 the synchronizer example illustrates how adherence to this principle can 
result in a simple proof of the validity condition required by the Correctness Theorem. 
In practice, there seems to be considerable flexibility in the choice of rely- and 
guarantee-conditions. Often significant simplifications in a correctness proof can be 
effected simply by adjusting the component module specifications. 

The apparent flexibility in the choice of rely- and guarantee-conditions in 
specifications raises the following somewhat disturbing question: What is to prevent us 
from writing component module specifications with extremely weak rely-conditions (e.g. 
true), and ridiculously strong guarantee-conditions (e.g. false), in order to simplify the 
proof of correctness? An implementation whose component module validity conditions 
are all of the form "true -* false" makes the validity part of a correctness proof 
extremely simple, but also vacuous. We can also consider more subtle, but still 
problematic specifications in which a module "guarantees" the application of some 
input to it -- something that seems to contradict our intuitive notion of what it means to 
be an input. 

Since a specification of the form "true -»• false," or a specification that guarantees 
the application of input ought to be regarded as meaningless, we should have some way 
of distinguishing these specifications from others that are meaningful. The theory we 
have set up so far provides no formal criteria for making such a distinction. What we 
require is a suitable notion of consistency of specifications, with respect to which 
obviously unrealizable specifications such as "true -♦ false" are inconsistent, and 
apparently reasonable specifications, such as the synchronizer component module 
specification, are consistent. 

In mathematical logic, a theory is consistent iff it has a model. Since the "models" 
of specifications are behaviors, it seems reasonable to define a specification to be 
consistent iff there is a behavior that satisfies it. If we take the term "behavior" in this 
definition to mean "arbitrary behavior," though, we do not obtain a stringent enough 
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notion of consistency. For example, every subset specification is consistent in this 
sense, since the empty behavior satisfies every subset specification. To obtain more 
stringent notions of consistency, we must restrict our interpretation of the term 
"behavior" to mean "realizable" or "computable" behavior. 

In this chapter, we examine a notion of consistency based on a model of 
concurrent computation called "l/O-systems." An l/O-system models a collection of 
concurrent processes that interact through coupled events. By viewing l/O-systems at 
various levels of abstraction we obtain the "l/O-behaviors," which we take as our class 
of computable behaviors. A specification is defined to be "l/O-consistent" iff there 
exists an l/O-behavior that satisfies it. The notion of l/O-consistency seems to be quite 
useful for distinguishing between meaningful and meaningless eventuality 
specifications. We develop a technique for proving state-transition specifications to be 
l/O-consistent and apply this technique to show the l/O-consistency of the 
synchronizer component module specification. 

5.1 l/O-Systems 

This section defines a model of asynchronous concurrent computation called 
"l/O-systems." An l/O-system is a system of nondeterministic processes that interact 
through coupled events. The nonnull events in which each process can participate are 
partitioned into "input events" and "output events." An input event for a process 
represents the stimulation of the process by its environment, and an output event for a 
process corresponds to the process responding to its environment. A process can 
choose whether or not it will produce output, but does not have the ability to control the 
application of input to itself. If a process wishes to produce output, then it cannot be 
prevented from doing so, although a process has no control over precisely when the 
output will be produced. 

The coupling of the processes in an l/O-system is described by a "system 
interface," the elements of which are "system events." Each system event is a vector 
with one component for each process in the system, and represents a possible 
simultaneous occurrence in the computation of the system. No system event contains 
more than one component output event, modeling the idea that at most one process can 
produce an output at any instant of time. 
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To describe the execution of an l/O-system, it is helpful to imagine the existence 
of a "scheduler," who controls the path of execution of the system. For each step of the 
system, the scheduler chooses a system event from the system interface. All processes 
then simultaneously take steps corresponding to the chosen system event. By the 
constraint that there is at most one output component of each system event, at most one 
process produces an output event in each step, and the other processes perform input 
steps or null steps. We are only interested in computations of an l/O-system that are 
"fair" in the sense that the scheduler selects each process to perform output steps 
often enough. 

We now give a formal definition of l/O-systems. We first define the notion of an 
l/O-interface, which is an interface whose non-X events are partitioned into input events 
and output events. 

Definition - An l/O-interface is an interface <£, A f , ln £ , Out^, where ln E C £ is a set of 
input events and Out £ C £ is a set of output events, such that the sets ln £ , Out 5 , {\ E } 
partition £. I 

We next define the "asynchronous product" of a collection of I/O- interfaces. 
Intuitively, the asynchronous product ® /€/ F f of the collection <£> /€/ of I/O- interfaces 
represents the set of all possible simultaneous occurrences in a system of processes 
where process / has interface F.. Each element of the asynchronous product interface is 
a vector of events from the component interfaces, such that at most one of the events in 
the vector is an output event. The fact that at most one event in each vector is an output 
event means that at most one process produces an output event at a time. This 
restriction is typical of asynchronous, interleaved execution models, and this is why the 
asynchronous product has been so named. 

Definition - The asynchronous product ® /€/ F. of a collection <Fj> j€l of l/O-interfaces is 
the interface F defined as follows: 

F = {I € n. e; F-. at most one f. is an output event} 

ln f ={£€£: f * \ F and no f. is an output event} 

Out f ={(€£: exactly one /. is an output event}. 
The maps it:. ® /€/ F t -*■ £., for / € /, that take a vector f_ to its rth component, are called the 
canonical projections associated with ® /€/ F.. I 
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In general, a system interface will not be the entire asynchronous product of the 
process interfaces, but rather only a sub-interface of the asynchronous product. The 
reason for using a sub-interface of the asynchronous product as the system interface is 
to capture possible coupling of events between processes. One kind of coupling that 
can be modeled in this way is the identification of events of distinct processes. For 
example, if the output event out for process one is to be identified with the input event in 
for process two, then we would include in the system interface the vector <out, iri>, in 
which process one performs an out event at the same time as process two performs an 
in event, but we would exclude from the system interface the event <out, X>, in which 
process one performs an out event while process two does nothing, and the event <X, 
in>, in which process two performs an in event while process one does nothing. Other 
kinds of coupling can also be modeled. For example, if the input event in for process 
two always occurs along with an output event out for process one, but the event our for 
process one need not occur along with an in event for process two, then the system 
interface would include the events <out, in> and <out, X>, but would exclude the event 
<X, in>. 

Our only requirement on the system interface is that to each event of a component 
process there is some system event that contains the given event as a component. This 
requirement ensures that each observation over a process interface has a faithful 
representation as an observation over the system interface. 

Definition - An embedding of an l/O-interface E into an l/O-interface F is an injective 
translation y.E -* F such that y(ln E ) C In^ and y(Out £ ) C Out^. I 

(Recall that the fact y is a translation implies that y(X £ ) = \ F .) 

Definition - A system interface for a collection <F,> /e/ of l/O-interfaces is an 
l/O-interface E C ® /€/ F { such that 

(1 ) The inclusion map y: E -» ® /€/ F l is an embedding. 

(2) Each map «, • y is onto F., where <w,> /€/ are the canonical projections 
associated with ® /€/ F r 

The collection of maps <w. • y> /€/ is called the canonical decomposition map associated 
withE. I 
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Each process in an l/O-system is represented by an "l/O-machine," which is a 
machine that cannot prevent the occurrence of input events. The l/O-machines in an 
l/O-system are required to be "explicit" in the sense that each nonnull step results in 
the occurrence of some non-X step. This assumption is justified because we think of an 
l/O-system as being a detailed, low-level model, in which all steps taken by processes 
result in explicit observable events, Later we will apply abstraction maps to the 
behaviors of l/O-systems to obtain less detailed, higher-level views of system behavior, 
in which steps can be taken that do not result in observable events. 

Definition - An l/O-machine of l/O-interface E is a machine M of interface E that is 
input-cooperative in the following sense: For all q € Q M and e € ln £1 there exists r € Q M 
such that <q, e, r> € Trans w . An l/O-machine M of interface E is explicit if every step 
<q, X, r> € Trans M has r = q. I 

Definition - An l/O-system is a tuple y = <£, ^X^, where / is a finite, nonempty set of 
process indices, E C ® /€; F, is a system interface, and each M t is an explicit l/O-machine 
of interface F . I 

We associate with an l/O-system 1 = <£, <Af / > /€/ >, a system machine M defined as 
follows: 

lnit M = n /£ , lnit M _ 

Trans w = {<fl , e, £ >: <q n 8,(6), r> € Trans w for all / € /}, 
where <5^ /€/ is the canonical decomposition map associated with E. I 

Definition - A computation for an l/O-system is just a computation for its system 
machine. I 

A computation X for an l/O-system projects to computations X (/) for each of its 
constituent machines in the obvious way. 

We will be interested only in the "fair" computations of an l/O-system. To formally 
define the notion of fairness, suppose S = <£, <M,.> /€/ > is an l/O-system and M is the 
system machine. Suppose a € M is a system state. We say that process i runs in a 
step <fl , e, £ > € Trans w if 5 ( .(e) is an output event for process /. We say that process i is 
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enabled in system state a if there is a step <fl , e, r > € Trans M in which process / runs. 

Suppose X is a computation for M. Process / is repeatedly enabled in X if for all t € 
[0, oo) there exists t' £[t, oo) such that process / is enabled in State x (f). Process / 
repeatedly runs in X if for all t € [0, oo) there exists f ' € [t , oo) such that process / runs in 
Step x (0. 

Definition - A computation X for an l/O-system is fair if for each process / in the 
system, if process / is repeatedly enabled in X, then process / repeatedly runs in X. I 

5.2 l/O-Behaviors and l/O-Consistency 

Each computation of an l/O-system produces an observation over the system 
interface. We call the set of all observations that are produced in fair computations of 
an l/O-system the "primitive behavior" of the system. This behavior is called 
"primitive" because it contains complete detail about the events that occur during a 
computation of the system. 

Definition - The primitive behavior PBeh(3) of a system of l/O-processes * is the set of 
all Obs x where X is a fair computation for f. I 

By applying abstraction maps to the primitive behaviors, we obtain additional 
(nonprimitive) behaviors. We call any behavior that is the abstraction of a primitive 
behavior an "l/O-behavior." An abstraction map can suppress information in a behavior 
by mapping two distinct events of the same type (either input or output) to the same 
event, or by mapping an output event to X. To ensure that an abstraction map faithfully 
preserves the input/output structure of a behavior, we require that an abstraction map 
never map an input event to A, and never map an input event and an output event to the 
same event. Furthermore, we require that each abstract input event be the image of 
some concrete input event. 

Definition - An l/O-abstraction map from the l/O-interface E to the l/O-interface D is a 
translation a\E-+D with the following properties: 

(1) a(Out £ ) C Out D U {\J. (a preserves outputs) 

(2) a(ln £ ) C ln D . ( a stridiy preserves inputs) 



(3) a is onto ln D . 



I 
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Definition - A behavior 8 € Beh(D) is an l/O-behavior of interface D iff there exists a 
system 5 of l/O-processes with system interface E and an l/O-abstraction map a.E-*D 
such that 8 = o(PBeh(3)). I 

The following result shows that the class of l/O-behaviors is a kind of completion 
under l/O-abstraction of the class of primitive behaviors. 

Theorem 5.1 - The class of l/O-behaviors contains all primitive behaviors and is closed 
under l/O-abstraction operators. 

Proof - Obvious from the definition of an l/O-behavior and the facts: 

(1 ) Identity translations are l/O-abstraction maps. 

(2) If a: F -» E and fi: E -* D are l/O-abstraction maps, then fi • a is an 
l/O-abstraction map. I 

By taking the l/O-behaviors as our class of realizable or computable behaviors, we 
obtain the notion of "l/O-consistency" of specifications. 

Definition - A specification S of l/O-interface D is l/O-consistent if there exists an 
l/O-behavior 8 of interface D such that 8 satisfies S. I 

5.3 Machine Characterization of l/O-Behaviors 

To obtain techniques for proving the l/O-consistency of state-transition 
specifications, it is convenient to have a direct characterization, not involving 
l/O-abstraction maps, of the l/O-behaviors of interface E . Such a characterization is 
provided by Theorem 5.4 below. Theorem 5.4 states that the l/O-behaviors are exactly 
the sets of observations produced by "productive step machines," which are 
l/O-machines plus some scheduling information. 

Definition - A productive step set for an l/O-machine M of interface £ is a set Prod C 
Trans M n Steps(Out e U{X £ }, Q M ) that contains no null steps. I 

I 
Definition - A productive step machine (PS-machine) of l/O-interface £ is a tuple 

<M, <Prod,> /€/ >, where M is an l/O-machine of interface £ and <Prod ( > /€; is a finite, 

nonempty collection of productive step sets for M, such that U, e; Prod, equals the set of 

all nonnull steps <g, e, r> € Trans w n Steps(Out £ U{\ £ }, Q M ). I 
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Suppose that <M, <Prod / > /€/ > is a PS-machine. The notions of the productive step 
set Prod, being enabled in a state of M and running in a step of M are defined in the 
obvious way. A computation X for M is fair if for each / € /, if Prod, is repeatedly enabled 
in X then Prod, repeatedly runs in X. Define the behavior Beh(M, <Prod / > €/ ) of the 
PS-machine <M, <Prod> e/ > to be the set of all Obs x where X is a fair computation of M. 

The following lemma states that every PS-machine has the same behavior as a 
PS-machine whose productive step sets are pairwise disjoint. 

Lemma 5.2 - If <M, <Prod,.> /€/ > is a PS-machine of interface E, then there exists a 
PS-machine <M', <Prod ; '> /€/ > of interface E such that the collection <Prod / '> /€/ is 
pairwise disjoint and such that Beh(/tf ', <Prod / *> /€/ ) = Beh(M, <Prod,> /e/ ). 

Proof - The idea of the proof is to include a dummy "tag" component in the state of M ', 
so that steps in Prod; ' write / into the tag component. This ensures disjointness, since if 
/ * /, then steps in Prod / and Prod y write different values into the tag component. 

Formally, define 

lnit M , = lnit w X/ 

Trans M . = {«q, k>, e, <r, m»: (1)-(3) below all hold} 

(1) <q, e, r>€Trans w 

(2) If <q, e, r> € U /€/ Prod,., then <q, e, r> € Prod,,,. 

(3) If <q, e, r> i U l€l Prod,, then m ■ k. 
Prod. ' = {«q, k>, e, <r, ;» € Trans M .: <q, e, r> C Prod.} 

It is straightforward to check that M ' is an l/O-machine of interface E and that the 
collection <Prod / *>,£, is pairwise disjoint. 

To show that <M ', <Prod / '> /€/ > is a PS-machine, we must show that the Prod, ' 
cover the nonnull output or X-steps in Trans M -. If «q, k>, e, <r, m» is a nonnull output 
or A-step in Trans M ., then either m * k or <q, e, r> is a nonnull output or X-step in 
Trans M . If m * k, then <q, e, r> € U /€; Prod,, by part (3) of the definition of Trans M . and 
hence <q, e, r> € Prod m by part (2) of the definition of Trans M .. By definition of Prod m ', 
we have that «q, k>, e, <r, m» € Prod m '. If <q, e, r> is a nonnull output or X-step in 
Trans M , then <q, e, r> € U /€/ Prod, because the Prod,, cover the nonnull output or X-steps 
in Trans M . By part (2) of the definition of Trans M ., we know that <q, e, r> € Prod m , and 
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hence «q, k>, e, <r, m» € Prod m ' by definition of Prod m '. 
We claim that Beh(M ', <Prod,. '> /€/ ) = Beh(M, <Prod> /€/ ). 

Case Beh(M ', <Prod,. '> /€/ ) C Beh(M, <Prod> (C/ ): 

Each computation X ' of <M ', <Prod ( . '> /€/ > defines a computation X of 
<M, <Prod> /e/ >, which we obtain simply by deleting the tag information from X. Suppose 
X ' is fair and that Prod, is repeatedly enabled in X. It is easy to see from the definition of 
Prod,. ' that if Prod / is enabled at time t in X, then Prod,. ' is enabled at time t in X '. Hence 
Prod ; ' is repeatedly enabled in X ', and thus repeatedly runs in X ' by the assumption 
that X ' is fair. If Prod,. ' runs at time f in X ', then by definition of Prod. ' it follows that 
Prod, runs at time fin X, so that X is fair. 

Case Beh(M, <Prod / > y£/ ) C Beh(M ', <Prod, '>, €/ ): 

Given a fair computation X of <M, <Prod / > /€/ >, we wish to construct a fair 
computation X ' of <M ', <Prod. '> /€/ > that generates the same observation. We construct 
X ' from X simply by filling in appropriate tag information to match the occurrence of 
productive steps in X, however we must do this in such a way that X ' is fair. 

To construct X ', let f:T-+ Steps(E, Q M ) be a history skeleton that spans X, where T 
= <t k > kC j{. Suppose Step x (f A ) = <q k , e k , g A + 1 > for each k € J>f. By a straightforward 
inductive construction involving fair scheduling of the elements of /, we can obtain a 
sequence <m k > k(L }{Ot elements of / such that «q k , m k >, e k , <q k + v m k+1 » € Trans^. for 
all k € if, and such that if <q k , e k , r k > € Prod y for infinitely many k € X, then m k = / for 
infinitely many k € X. The history skeleton f ' that maps t k to the step «q k , m k >, e k , 
*Qk + v m k + 1^ tnen defines * ne desired fair computation X ' of M '. I 

The lemma below shows that the class of behaviors of PS-machines is closed 
under l/O-abstraction. 

Lemma 5.3 - Given a PS-machine <M, <Prod.> €/ > of interface E, and an l/O-abstraction 
map a: E ^ D, there exists a PS-machine <M ', <Prod | . '> /e/ > of interface D such that 
Beh(Af ', <Prod / '>, e/ ) = o(Beh(M, <Prod / > /€/ )). 

Proof - The basic idea of the proof is simple: M ' and the Prod. ' are defined by taking 
the images of M and the Prod, under a. There is one problem with the straightforward 
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execution of this idea: the Prod,. ' might contain null steps. We solve this problem by 
introducing into the state of M' an "idling counter," which is a boolean component 
whose only purpose is to change state upon execution of productive steps. 

Formally, define <M ', <Prod, '>, €/ > as follows: 

<V =Q W X{0,1} 
lnit M - = lnit M x {0,1} 

Trans M - = {«q, o>, a(e), <r, c»: (1) and (2) below both hold} 

(1) <q, e, /■> € Trans w 

(2) If <q, e, r> € U ;€/ Prod,, then c = 1 -b, otherwise c = b. 
Prod. ' = {«q, b>, a(e), <r, c» € Trans M .: <q, e, r> € Prod.}. 

We claim that M' is an l/O-machine. It is clear that lnit w . is nonempty. Part (2) of 
the definition of Trans M . does not prevent Trans M . from containing all null steps, since 
no such step can be in U /€/ Prod,. Thus M' is a machine. To show that M ' is 
input-cooperative, suppose <q, b> € Q M . and d € ln . Since o is onto ln D and preserves 
outputs, there exists e € ln f with a(e) = d. By the input-cooperative property of M, there 
exists r with <q, e, r> £ Trans M . Since <q, e, r> t U /€; Prod, by the fact that e is an input 
event, it follows that «g, b>, d, <r, b» € Trans w .. 

We next show that <M ', <Prod, >, € ^ is a PS-machine. By definition Prod, ' C 
Trans M . for all / € /. Since each step in Prod, is an output or X-step and o preserves 
outputs, it follows that each step in Prod, ' is an output or X-step. Each Prod, ' contains 
no null steps because the idling counter is complemented in each step in Prod, '. To see 
that every output or X-step in Trans M> is in some Prod,', note that because a strictly 
preserves inputs, each output or X-step in Trans v . cannot be the image of an input step 
in Trans M , and therefore must be the image of an output or X-step in Trans w . Since the 
Prod, cover all output or X-steps of Trans w , ft follows that the Prod, ' must cover all 
output or X-steps of Trans M '. 

We claim that Beh(Af',<Prod,'>, €/ ) = a(Beh(/lf , <Prod l >, c ,)). 
Case a(Beh(M, <Prod,>, € ,)) Q Beh(M ', <Prod, '>, c/ ): 

Each computation X of M maps in an obvious way (by taking the image of the 
observation part under o, and deleting the idling counter from the state part) to a 
computation X ' of M\ such that Obs x . = a(Obs x ). It suffices to show that if X is fair, 
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then so is X '. Suppose that X is fair. Fix /' € /, and suppose that Prod, ' is repeatedly 
enabled in X '. We claim that Prod, ' repeatedly runs in X '. By definition, Prod, ' is 
enabled in state q iff Prod, is enabled in state q. It follows that Prod, is repeatedly 
enabled in X, and hence by fairness of X, that Prod, repeatedly runs in X. By definition of 
Prod, ', if Step x (f) € Prod,, then Step x -(f) € Prod, '. Thus Prod, ' repeatedly runs in X '. 

Case Beh(M ', <Prod, '> /€/ ) C a(Beh(M, <Prod,>, e/ )): 

Suppose that x ' € Beh(M ', <Prod, '> /€/ ), and let X ' be a fair computation of M ' in 
which the observation x ' is generated. We will construct a fair computation X of M, 
such that <*(Obs x ) = x '. The idea is simply to choose inverse images under a of the 
steps in X ', however this must be done carefully to ensure fairness. 

Let T = <t k > ke jf be a skeletal sequence that spans X '. Suppose Step x ,(t k ) = 
«q k , b k >, d k , <r k , c k » for each k € Jf. 

For each k, since «q k , b k >, d k , <r k , c k » € Trans M -, we can select e k such that d k « 
a(e k ) and <q k , e k , r k > € Trans M . Because a might map two different e's to the same d, we 
can't necessarily select the e h in such a way that for each / € /, the step <q k , e k , r k > € 
Prod, iff «q k , b k >, d k , <r k , c k » € Prod,'. However, by making sure that we don't 
persistently neglect some Prod, ', we can select the e k in such a way that for each / € /, if 

<<q k> b k > ' d k> ^k' c k >> € Prod ; ' for '"finitely many k, then <q k , e k , r k > € Prod, for infinitely 
many k. 

The function f that takes t k to the step <q k , e k , r k > is a history skeleton over E M and 
Q M . By Lemma 3.5 there is a unique history X such that / spans X. It is easily verified 
that X is a computation of M, with o(Obs x ) = x '. To show fairness, fix / € / and suppose 
that Prod, is repeatedly enabled in X. We claim that Prod, repeatedly runs in X. From the 
definition of Prod. ' we know that Prod, ' is repeatedly enabled in X '. By the fairness of 
X ' we know that Prod, ' repeatedly runs in X '. This implies that <q k , d k , r k > € Prod y ' for 
infinitely many k, and hence by construction that <q k , e k , r k > € Prod, for infinitely many k. 
It follows that Prod, repeatedly runs in X. I 

The following theorem is our desired characterization of the l/O-behaviors: a 
behavior is an l/O-behavior iff it is the behavior of a PS-machine. 

Theorem 5.4 - Suppose D is an l/O-interface. Then a behavior B € Beh(D) is an 
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l/O-behavior of interface D iff fi = Beh(/W, <Prod> ;€/ ) for some PS-machine <M, 
<Prod y > /€/ > of interface D. 

Proof - => Since the class of behaviors of PS-machines is closed under 
l/O-abstraction by Theorem 5.1 , it suffices to show that every primitive behavior fi is the 
behavior of a PS-machine. Suppose fi = PBeh(i), where f = <E, <M / > /£/ > is an 
l/O-system. We associate a PS-machine <M, <Prod / > /e/ > with * as follows: The machine 
M is the system machine for 5. The set Prod, is the subset of Trans M in which process /' 
runs. Since a step in which process / runs is always an output step, it is clear that Prod / 
is a productive step set for M. Since every nonnull output or X-step in Trans M is in fact 
an output step for some process / € /, and hence is in Prod;, it follows that the Prod, sets 
cover the nonnull output or A-steps in Trans M . 

It is obvious that the set of fair computations of the system f is exactly the set of 
fair computations of the PS-machine <M, <Prod,> /€/ >, and thus PBeh(^) = 
Beh(M, <Prod,> /€/ ). 

<= Suppose that <M, <Prod,> /€/ > is a PS-machine of interface D. We construct an 
l/O-system * = <£, <Af / >. (E/ > and an l/O-abstraction map a: E -* D, such that 
Beh(M, <Prod / > /€/ ) = a(PBeh(:f)). 

Without loss of generality we make the following three assumptions about 
<M, <Prod.> /€/ >: 

(1 ) The set lnit w of initial states for M contains exactly one state q Q . 

(2) For all q € Q M and all e € ln D , there is a unique r € Q M such that <q, e, r> € 
Trans M . 

(3) Prod . D ProaV = for / * j. 

A PS-machine <M ', <Prod ; '> ( . £/ > that does not have these three properties can easily be 
transformed, without changing its behavior, into a PS-machine <M, <Prod> /€/ > that does 
have these properties. We first obtain properties (1 ) and (2) by buffering input events in 
an input queue in the order that they occur so that the change of state associated with 
an input event is just to append the event to the end of the input queue. All 
nondeterministic choice, including the choice between multiple initial states, is 
absorbed into the output steps. 
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Formally, we transform the PS-machine <M\ <Prod.'> /€ ,> into a PS-machine 
<M ", <Prod ( . "> (€/ > by defining State M - to consist of all pairs <q, u>, where q is either an 
element of State M< or the distinguished symbol ±, and u € ln £ *. The single initial state 
of M " is the state <±, \>. The transition relation Trans M » consists of all steps «o, u>, e, 
<r, v» such that 

- If e € \n E then r = q and v = ue. 

- If e € Out £ U {X E }, then v = X, and either 

(a) <q,ue, r> is in Trans M .*, or 

(b) q = JL and <s, ue, r> € Trans M .* for some s in lnit M .. 

The set Prod, " consists of all steps «q, u>, e, <r, v» € Trans M .. such that for some state 
s of M ', the step <s, e, r> € Prod ( . ', and in addition, either q * ± and the step <q, u, s> is 
in Trans M • , or q = ± and for some q ' € lnit w . the step <q ', u, s> is in Trans w .* . 

Once <M", <Prod ( . "> ( . e; > with properties (1) and (2) is obtained, it can be 
transformed into <M, <Prod / > /e/ > with all three properties by an application of Lemma 5.2. 

We now proceed to the construction of 5. The idea is as follows: The system S will 
contain one process for each / € /. The processes in :f perform a lock-step simulation of 
the machine M. The interface for each of the processes in the system f consists of the 
null event, the input events of D, and the set of all productive steps for M. The input 
events for process / wilt be the input events of D and the steps in U /€; _ {/J Prod^ The 
output events for process / will be the steps in Prod.. Each process keeps track of the 
current simulated state of M, and permits an output event to occur only if the event 
corresponds to a step of M from the current simulated state of M. To ensure that the 
input-cooperative property holds, process / imposes no requirements on the state from 
which a step in Prod y . can occur, if/ * /. 



Formally, define the l/O-interfaces F. as follows: 
F, -{X^l + lr^ + U^Prod, 

,r V, = ln o + ( U /€K0 Prod /> 



Out, = Prod, 



Define the system interface E Q F = ®, €/ F f as follows: 
E = U € F: f, * f. for all /,/ € /} U {\ f } 



\n £ = E n \n F 
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Out £ = ED Out f 
It is easy to see that the inclusion map y. E -»• F is an embedding. For each f € In, , the 
identically / vector <f> j€l is in £. By the assumption that the Prod, are pairwise disjoint, it 
follows that the identically / vector </> /e/ is in E for each f € Out f as well. This shows that 

i 

w j ° y is onto F., where the », are the canonical projections associated with F. 

Define a: E -*■ D to be the translation that behaves in the following way on the 
identically / vector </> /€/ € £: 

- lf/ein ,thena(</> /£/ ) = f. 

- If / = <g, d, r> € Prod, for some / e /, then a(</> /£/ ) = d. 

We claim that a is an l/O-abstraction map. It is clear that a is onto ln . The map a 
preserves outputs because if the identically / vector is an output event of E, then / € 
Prod / for some / and hence / is an output or X-step. To show that a strictly preserves 
inputs, suppose the identically f vector </> ;€/ is an input event of E. Then / € ln D , so 
a«f>. ei ) = fC\n D . 

The machines M. axe defined as follows: 
S = F ' 

lnit M, = lnit M = ^0> 

Trans M = {<q, f, r>: one of (1)-(4) below holds} 

(1) f = X p andr = q, 

(2) f € ln D and <q, f, r> € Trans w . 

(3) f = <g ', d, r> € Proo^ for some/ * /. 

(4) / = <q, d, r> € Prod r 

Obviously M. is a machine and every step <q, K,r>€ Trans., has r ■ g. To see that Af ; 
is input-cooperative, suppose q € Q u and / € ln c . Then either / € ln n or / € Prod, for 
some /' * /'. If / € ln Q then f is enabled in state g by part (2) of the definition of Trans M 
because M is input-cooperative. If / = <g ', d, r> € Prod y for some / * i, then / is enabled 
In state g by part (3) of the definition of Trans., . 

A straightforward induction establishes that if a is a reachable state of the system 
y, then g ( . = q. for all /', / € /. This argument uses the assumed uniqueness of the initial 
state of M, plus the assumption that a state g and an event e € ln f uniquely determine a 
state r such that <g, e, r> € Trans M . Intuitively, since the processes in S do not interact 
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with each other during input steps, the uniqueness assumptions are needed to ensure 
that all processes reach the same new state in each such step. 

There is an obvious correspondence between the steps of the machine M and the 
steps of the system *. Specifically, each step s = <g, d, r> of M determines a step s ' = 
<fl . e. L > of 3 under the definitions: 

- g is the identically q vector 

- r is the identically r vector 
■ e = \ E , if s is null 

= <d>, e/ , ifd€ln 

= <s> /€/ , if s is a nonnull output or X-step. 

It easy to see that a step s of M is enabled in state q of M iff the corresponding step 
s ' is enabled for the system t in state <Q> /€/ . The correspondence between the steps of 
M and the steps of J therefore defines a bijection between the set of computations of M 
and the set of computations of if, such that if X ' is a computation of ? and X is the 
corresponding computation of M, then Obs x = a(Obs x .). Furthermore, a step s of M is 
in Prod, iff process / runs in the corresponding step s ' of *, so that fairness is preserved 
in both directions of this correspondence. It follows that a(PBeh(i)) = 
Beh(M, <Prod,>. e/ ). I 

The following two properties of l/O-behaviors are easily derived from the 
PS-machine characterization. 

Corollary 5.5 If B is an l/O-behavior of interface E, then B * 0. 

Proof - Suppose B = Beh(M, <Prod,>. € ,). It suffices to show that there is a fair 
computation of M. We construct a sequence q Q , q v ... of states of M, and a sequence 
e , e v ... of events of E , such that the following properties hold: 

(1 ) <q k , e k ,q k + ,>£ Trans w for all * € if, 

(2) For each / C /, either Prod, is enabled in only finitely many of the q k , or else 
the step <q k , e k , q k + ,> is in Prod ; for infinitely many k. 

Letting t k = k for each natural number k and applying Lemma 3.5 yields a fair 
computation of M. 
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To construct the q k and e^, first let q Q € lnit M be chosen arbitrarily. We maintain a 
running assignment of priorities to the elements of A so that at each stage of the 
construction / is more urgent than / iff a step in Prod, has been chosen less recently than 
a step in Prod y . At stage k, where k > 0, we choose e k and q k + 1 so that <q k , e k , q k + ,> € 
Prod,, where / is the most urgent element of / such that Prod ( . is enabled in state q k . If no 
Prod ( . is enabled in state q k , then we let e k = A and q k + 1 

A behavior 8 is asynchronous if whenever x € B and f: [0, oo) -♦ [0, oo) is an 
order-isomorphism, then x <> / € B. 

Corollary 5.6 - l/O-behaviors are asynchronous. 

Proof - Straightforward from the observation that if X is a fair computation of a 
PS-machine <M, <Prod,>. €/ > and f: [0, oo) -* [o, oo) is an order-isomorphism, then X <• / is 
also a fair computation of <M, <Prod.> /€/ >. I = q k . I 

5.4 Examples of l/O-Behaviors 

In this section we give two examples of l/O-behaviors and an example of a 
behavior that is not an l/O-behavior. 

Example 1: An l/O-Behavior: 

As an example of how l/O-behaviors can be used to model a system capable of 
satisfying eventuality requirements, imagine that we wish to model the behavior of a 
"black box" to which input stimuli can be applied by pressing a single button ; and from 
which output can be observed by flashes of a single light bulb. The black box has the 
property that every press of the button is later followed by a flash of the light bulb, and 
no flashes of the bulb occur unless the button has been pressed at least once since the 
time of the most recent previous flash. 

The interface of such a black box is the l/O-interface E with E = {\, button, flash}, 
ln £ = {button} and Out £ = {flash}. The behavior of the black box is defined by a 
PS-machine M of interface E. Intuitively, a push of the button sets a flag in the state of M 
to true. A flash of the light can occur only when the flag is true, and causes the flag to 
be reset to false. There is one productive step set Prod, which contains exactly those 
steps in which flashes occur. 
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Formally, 



E» = E 



Q M = {true, false} 

lnit M = {false} 

Trans M = {<o, button, r>: r = true} U (<true, flash, false>} U 

{<q,X,Q>:q€0 M }. 
Prod = {<q, flash, r> € Trans M } 
That <M, Prod> is a PS-machine of interface E is easily checked. 

Let e = Beh(M, Prod), so that B is an l/O-behavior. Through analysis of the fair 
computations of M it can be shown that an observation x € Obs(E) is in B iff there is a 
surjective total function /: [t € [0, oo): x(f) = button} -»{/'€ [0, oo): x(r *) = flash} such 
that for all t € [0, oo), f(t) is the least t ' € (f, oo) such that x(f ') = flash. That is, an 
observation x is in B provided that in x, every push of the button "causes" a future flash 
of the light, and every flash of the light is caused by some collection of recent past 
pushes of the button. 

Example 2: Two Productive Step Sets 

We can give an example of an l/O-behavior that is not the behavior of a 
PS-machine with one productive step set. Let the interface E be defined by: E = 
{X, button, flashl, flash2}, where ln £ = {button} and Out E = {flashl, flash2}. Let B be 
the set of all x € Obs(£) such that the following properties hold: 

(1) Occurrences of flashl appear only between the 2Ath and 2fc + 1st 
occurrences of button, where k 6 X. 

(2) Occurrences of flash2 appear only between the 2A + 1st and 2(K + 1)st 
occurrence of flash. 

(3) x contains infinitely many occurrences either of flash 1 or flash2 

(4) If x contains infinitely many occurrences of button, then it contains infinitely 
many occurrences of both flashl and flash2. 

It is straightforward to show that S is the behavior of a PS-machine of interface E with 
two productive step sets, one that governs the occurrence of flashl events and one that 
governs the occurrence of flash2 events. 
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Suppose 8 is the behavior of a PS-machine <M, Prod> with one productive step 
set. Construct a computation of M by repeating the following procedure: Run M until a 
flash 1 event is produced, then run M for two steps containing a button input. It is always 
possible to obtain the flash 1 events in this construction, since otherwise we could 
construct a fair computation in which only finitely many flashl events and no f!ash2 
events occur. It is always possible to run the button events by the input-cooperative 
property of M. 

The above construction yields a computation X of M that must be fair, since it 
contains infinitely many steps in which the output event flashl occurs, and which must 
be in the single productive step set Prod because Prod contains all output steps of M. 
However, X generates an observation in which infinitely many button events occur, but 
no flash2 events occur. 

Example 3: A Non-I/O-Behavior 

We can also give an example of a set that is demonstrably not a l/O-behavior. 
Define the l/O-interface E as follows: 

E = {X, button, flash} 

ln f = {button} 

Out £ = {flash}. 
Let the behavior B € Beh(E) be the set of all x € Obs(E) such that x contains an infinite 
number of occurrences of flash, and such that either the number of occurrences of 
button in x is finite or (# flashes in x on the interval [0, t))/ (# buttons in x on the interval 
[0,f))-*0asf-»oo. 

We argue that B is not an l/O-behavior of interface £. Suppose <M, <Prod / > /€/ > is a 
PS-machine of interface E, whose behavior is B. Construct a computation X for M by 
repeating the following procedure: Run M without input until a flash event is produced, 
then run M for one step with a button input. We can run M until a flash event is 
produced by always trying to take steps in which flash events are produced, if possible, 
otherwise taking some other productive step. During this construction, we make sure to 
use a fair scheduling algorithm to determine which of the Prod, should be executed at 
each step. We can never reach a state in which no productive steps are enabled, 
otherwise we could construct a fair computation in which only finitely many flash events 
are produced. We can run M at any time with a button input by the input-cooperative 
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property of M. 

The above construction yields a computation X of A* that must be fair, since the fair 
scheduling of the Prod,, ensures that every repeatedly enabled Prod, will be repeatedly 
run. However, computation X generates an observation x that contains infinitely many 
occurrences of button events, and in which the ratio of the density of flash events to 
button events approaches one in the limit, rather than zero. This contradicts the 
assumption that Beh(Af, <Prod / > /€/ ) = fl. 

5.4.1 Proving l/O-Consistency 

From the PS-machine characterization of the l/O-behaviors we obtain the 
following test for l/O-consistency of subset specifications. 

Theorem 5.7 - Suppose that S is a subset specification of l/O-interface E . Then S is 
l/O-consistent iff there exists a PS-machine <M, <Prod,> /€/ > of interface f such that 
Beh(M, <Prod,> /€/ ) C 0(S). 

Proof - Obvious. I 

If S = <M, V> is a state-transition specification, then to show the l/O-consistency 
of S, it suffices to define a collection of productive step sets for Af, such that every fair 
computation of M is in the set V of valid computations. 

Corollary 5.8 - Suppose that S ■ <M, V> is a state-transition specification of 
l/O-interface E. Suppose that <M, <Prod,> /€ ,> is a PS-machine of interface £. If every 
fair computation of M is in V, then S is l/O-consistent. 

Proof - Since <M, <Prod / > /e/ > is a PS-machine of interface E, it follows that 
Beh(M, <Prod,>, € ,) is a l/O-behavior of interface E. Since every fair computation of M is 
in V, we know that Beh(W, <Prod / >. €/ ) C 0(S). By Theorem 5.7, S is l/O-consistent. I 

To illustrate the use of this result, we apply it to a simple example specification: A 
neuron is a module with a single input event in, and a single output event out . The state 
set for the neuron is the set {ff, tt}. At any instant of time, if the state of the neuron is tt, 
then the neuron is said to be excited, otherwise the neuron is said to be inhibited. 
Initially the neuron is excited. An in event can occur at any time, and causes the neuron 
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to become inhibited. If the neuron is excited, then it can fire, producing an out event, 
and then becoming inhibited. The neuron should satisfy the condition, "If the neuron 
becomes excited and remains that way, then eventually it will fire." 

The neuron module description can be formalized as a state-transition 
specification. 

E NEU = {X, in, out} 
ln NEU = {in} 
Out NEU = {out} 

Q NEU = {ff, tt} 

lnit NEU = {tt} 
A step <q, e, r> € Trans NEU iff either e = X and r ■ q or one of the conditions (in), (out) 
below holds: 

(in) e = in and r = ff 

(out) e = out and q = tt 

The neuron module validity condition is defined by: 

Valid NEU e □(□(Now = tt) -» O(0ccurs = out)), 

To show the l/O-consistency of the neuron specification, we define a single 
productive step set Prod NEU as follows: 

<q, e, r> € Prod^ iff e = out, q = tt, and r = ff. 
It is clear by inspection that A^ EU is input-cooperative, and that Prod NEU is a productive 
step set for M NEU . To show the l/O-consistency of the neuron specification, we must 
show that every fair computation of Af NEU is valid. That is, 

Comp NEU a Fair^u 1= Valid NEU , 
where 

Fair*^ e DOEnabled'^Now) -► DOProd^Now, Occurs, After) 

Enabled NEU (g) 3 (3e€E NEU , r € Q mu ) Prod^q, e, r). 
We claim the stronger property 

Fair*" 1- Valid'*". 
To show this, we use the neuron module specification and the definition of Prod NEU to 
expand the term Fair NEU . From the definition of Prod^ u we obtain 
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Enabled NEU (g) s q = tt, 
and hence that 

Fair NEu s no(Now = tt) -» DO(Now = tt a Occurs = out A After = ft). 

By straightforward temporal and propositional reasoning it is now easy to see that 
□0(Now = tt) -♦ DO(Now = tt a Occurs = out a After = ff) 
N D(D(Now = tt) -+ O(0ccurs = out)), 
That is, if we suppose that 

(1) whenever the state repeatedly takes on the value one then it is also 
repeatedly the case that an out event occurs (which takes the state from one to zero), 
then we are entitled to conclude that 

(2) whenever the state is persistently one after some instant, then there is a 
later instant at which an out event occurs. 

We can use the PS-machine characterization of the l/O-behaviors to show the 
l/O-inconsistency of a slightly stronger version of the neuron specification, obtained by 
using the stronger validity condition 

Va!idJ[ EU s D(Ncw = tt - O(0ccurc = out)). 
This condition states that if the neuron is ever excited for a single instant, then it must 
eventually fire. Suppose there is a PS-machine <M, <Prod,> /C/ > of interface £ NEU such 
that Beh(M, <Prod / > /€/ >) satisfies the strong neuron specification. Construct a 
computation of M as follows: Run M for one step with input in, and then repeatedly run 
productive steps of M if possible, otherwise null steps, being sure to schedule the 
occurrences of Prod, fairly. The result is a fair computation X of M. 

Since the observation x = Obs x satisfies the strong neuron specification, there 
must exist a valid computation X ' of M NEU such that Obs x - = x. In X ', the neuron 
module is excited at time 0, an in event occurs at time 0, and no input events occur after 
time 0. Consequently, the neuron module is inhibited after time 0, and thus no out 
events can appear in x because X ' is a computation of M^. Thus, in the computation 
X ' of M NEU , the neuron module is excited at time but no out events subsequently 
occur. This means that the computation X ' of A^ EU fails to satisfy the validity condition 
ValidJ[ EU , a contradiction. We conclude that the PS-machine <M, <Prod J > IG > cannot 
exist and the strong neuron specification is l/O-inconsistent. 
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5.4.2 l/O-Consistency of the Specification SC 

As an extended example of an l/O-consistency proof, we prove the 
l/O-consistency of the synchronizer component module specification. For the 
productive step sets, we use the sets Prod ron , Prod token ouV and Prod request out , defined 
as follows: 

Prod run (q, e, r) = e = run a Trans 80 ^, e, r) 

Prod token_outfa' e > r ) s e = to k e n -Out A Trans 80 ^, e, r) 

Prod request_out^' e > r ) s e = request_out a Trans 80 ^, e, r). 
It is easily checked that <M SC , <Prod run , Prod tokenout , Prod requesLoot » is a PS-machine of 
interface E 80 . 



We must show that each fair computation is valid; that is, 
where 



Comp 80 * a Fairf£ a Fair 80 ^, A Fair 8 ^^, >- Valid 80 , 



Fairf^ s DOEnabledf£(Now) - 

OOProdf^Now, Occurs, After) 

Fair 2L_out s nOEnabled Sen.out( N ° W ) "> 

DOProd^^Now, Occurs, After) 

Fair Su«st.out s DOEnaWedg u(BUwl (Now) - 

DOProdg^^Now, Occurs. After) 
and each Enabled 80 *^), where / € {run, token_out, request_out}, is a formula that 
expresses the conditions under which Prodf is enabled in state q. Using the 
definitions of the Prod, given above, we derive the following expressions for Enabled^, 

Enabled .oken.o«t' find Enab,ed request_out : 

Enabled^Jq) m q(ustate) ■ trying a q(token) * 

Enabled token ^(q) s q(ustate) * running a q(token) * 

Enabled requestout (q) = q(token) = 

To show 

Comp 80 * a Fair* a Falrj*^ a Fairg uest00t K Valid 80 , 
we assume Comp 80 *, Rely 80 , -iGuar 80 , Fair^, Fair tokenoot , and Falr nqueiLout , and 
derive a contradiction. That is, we consider a fair computation in which the 
synchronizer component module rely-conditions are satisfied, but in which the 
guarantee-conditions are not satisfied. If -"Guar 80 holds, then either 

(A) -«D(Now(ustate) = trying -* 0(Now(ustate) * trying)) 
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or 

(B) -iD(Occurs = requesUn) -* O(0ccurs = token_out)). 
Thus the proof can be split into two cases, one headed by assumption (A), and the other 
by assumption (B). 

Case (A): Suppose that (A) holds. Then by temporal reasoning, we have 

0(Now(ustate) = trying a D(Now(ustate) = trying)) 
(*) OD(Now(ustate) = trying) 

That is, it is persistently the case that the user process is trying. By definition of 
Trans sc , the following is valid: 

Comp sc * N= D(Occurs = run -+ After(ustate) * trying) 
and thus, using the temporal tautology M D(<p(After) -♦ Oqp(Now)), that 

Comp sc A K» OD(Now(ustate) ■ trying) -» OD(Occurs * run). 
Intuitively, since occurrence of run results in the user process leaving the trying state, if 
the user process is persistently trying, then it must be the case that a run event 
persistently does not occur. Applying this to formula (•) yields 

OD(Occurs * run a Now(usiate) = trying) 
That is, it is persistently the case that the user process is trying but a run event never 
occurs. Using the definition of Prod, „, we conclude 

run 

OD(-<Prod run (Now, Occurs, After) a Now(ustate) = trying). 
By applying of the hypothesis that Fair run holds, we obtain 

OCK-iEnabled^Now) a Now(ustate) » trying). 
Using the expression for Enabled run obtained above, we have 

OD(Now(token) = a Now(ustate) = trying). 
That is, it is persistently the case that the synchronizer component module possesses 
no tokens, and the user process is trying. Using the hypothesis that Fafrfequeatjait holds, 
we obtain 

DO(Occurs = request_out) a OD(Now(token) = 0). 
That is, it is repeatedly the case that request jout occurs, but persistently the case that 
the synchronizer component module possesses no tokens. Applying the hypothesis 
that Rely 80 holds, we conclude 

DO(Now(token) * 0) a OD(Now(token) » 0). 
That is, it is repeatedly the case that the synchronizer module possesses a token, but 
persistently the case that the synchronizer module possesses no tokens. This is a 
contradiction, and we conclude that case (A) is impossible. 
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Case (B): Suppose that (B) holds. Then by temporal reasoning, we have 

O(0ccurs = requesUn a D(Occurs * token_out)). 
That is, eventually there is a point at which a request for the token is received, but no 
token is ever sent in response. Using the definition of Prod tokenout , and temporal 
reasoning, we obtain 

OD->Prod tokenou ,(Now, Occurs, After). 
Application of the hypothesis that Fair token ^ holds, we have 

OD-.Enabled tokenoot (Now). 
That is, it is persistently the case that a token_out event is not enabled. Using the 
expression for Enabled, oken out obtained above yields 
{•*) OD(Now(ustate) = running v Now(token) = 0). 

Thus, it is persistently the case that either the user process is running or the 
synchronizer component module possesses no token. We now use the temporal 
tautology N ODfo v *) -► (DO9 v OD+). Intuitively, this says that if it is persistently 
the case that 9 v + holds, then either 9 holds repeatedly, or else + holds persistently. 
Application of this tautology to (* *) gives 

DO(Now(ustate) = running) v OD(Now(token) = 0). 
That is, either the user process is repeatedly running, or the synchronizer component 
module persistently has no token. We now split the proof into two subcases, depending 
upon whether 

(B1) DO(Now(ustate) = running) 
or 

(B2) OD(Now(token) = 0) 
holds. 

Subcase (B1): Suppose that (B1) holds. Application of the hypothesis that Rely sc holds 
gives 

DO(Now(ustate) = running) a DO(Now(ustate) * running). 

Next, we use the temporal tautology 

N (D09(Now) a DO-^Now)) -► DO(qp>(Now) A -iy(After)). 
Intuitively, if it is repeatedly the case that 9 holds of the current state, and it is repeatedly 
the case that -19 holds of the current state, then it must repeatedly be the case that a 
point is reached where 9 holds of the current state and -19 holds of the "next" state. 
Application of this tautology in the present situation gives 
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□0(Now(ustate) = running a After(ustate) * running). 

In addition, we need the following invariance property: 

Comp sc * M^ D(Now(ustate) = running -» Now(token) * 0). 
The validity of this sentence can easily be shown by Corollary 3.7, and the details are 
omitted. Using this, plus the fact that 

N (Vq/€State, e€Event)((Trans sc (q, e, r) a q(ustate) = running 
a r(ustate) * running) -♦ r(token) = q(token)), 
which is verified by case analysis on e, we obtain 

DO(After(ustate) * running a After(token) * 0). 

Let us examine the intuitive content of the preceding steps. If the user process is 
running in the current state and not running in the "next" state, then the following must 
be true: Since the synchronizer component module must possess a token whenever the 
user process is running, and no event that takes the user process out of the running 
state can affect the number of tokens possessed, it must be the case that the 
synchronizer component module possesses a token in the next state as well. 

Another use of the temporal tautology N D(«p(After) -»• Oy(Now)), we obtain 
DO(Now(ustate) * running a Now(token) * 0), 
which is a contradiction with formula (**). We conclude that subcase (B1) is 
impossible. 

Subcase (B2): Suppose that (B2) holds, that is 

OD(Now(token) = 0). 
Then by definition of Enabled reques , „„, we have 

ODEnabled reque8Lout (Now), 
and thus by the hypothesis that FaiiVeauesLout holds, we infer 

DO(Occurs = requesLout). 
That is, it is repeatedly the case that request jout events occur. By the hypothesis that 
Rely sc holds, we conclude 

DO(Now(token) * 0) 
a contradiction with (B2). We conclude that subcase (B2) is impossible, and hence that 
case (B) is impossible. 
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Since both cases (A) and (B) have been shown to be impossible, we conclude that 
the original hypotheses are contradictory, and thus the synchronizer component 
module specification is l/O-consistent. 

5.5 Composition of l/O-Behaviors 

We have previously shown that the class of l/O-behaviors is closed under the 
abstraction operators associated with the l/O-abstraction maps. In this section, we 
define the class of "l/O-decomposition maps," and show that the class of l/O-behaviors 
is also closed under the composition operators associated with these maps. 

5.5.1 l/O-Decomposition Maps 

When we defined the notion of a system interface above, we noted that there is a 
canonical decomposition map (and hence a composition operator) associated with 
each system interface. We would now like to extend the notion of composition 
associated with system interfaces so that we can view behaviors of non-system 
interfaces as a composition of component behaviors. The most natural way to do this is 
to require that the the domain of a decomposition map be a system interface only up to 
isomorphism. 

Definition - An isomorphism from the l/O-interface E to the l/O-interface D is a 
bijective translation y.E -* D such that y and y' 1 are embeddings, I 

Definition - An l/O-decomposition map from the l/O-interface E to the collection of 
l/O-interfaces <f,>, €/ is a vector <8? l€l of translations, where 5,: E -* F. t with the following 
property: There exists a system interface E ' C ® /e/ F j and an isomorphism y. E -* E', 
such that 8, = S j ' • y for all ; € /, where <S t > /€/ is the canonical decomposition map 
associated with E '. I 

From this definition, we can immediately derive a number of properties of the 
l/O-decomposition maps. 

Lemma 5.9 - If <8> l£l is an l/O-decomposition map from E to ^^e/. then 

(1 ) e * e ' implies 8.(e) * 8.{e ') for some / € /. (£ is injective) 

(2) 5,(ln P ) C In. U {K } for all / € /. {& preserves inputs) 

i e r, r. 
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(3) If e € Out £ then 8 ( .(e) € Out, for some /' € /. (S. strictly preserves outputs) 

(4) 5 1 {Out, ) PI a/^Outp) = whenever /' * /'. (Compatible Coupling Property) 

(5) 6 ( . is onto F f for all / € /. 

Proof- Straightforward. I 
5.5.2 Closure Proof 

We can now prove that the class of l/O-behaviors is closed under the composition 
operators associated with l/O-decomposition maps. 

Theorem 5.1 - Suppose <$,>/€/ is an l/O-decomposition map, where S:. E -» F r If B, is 
an l/O-behavior of interface F, for each / € /, then £ - 1 (£ ) is an l/O-behavior of interface 
£. 

Proof - Suppose that for each i € /, <M,, <Prod /a > a€A > is a PS-machine of interface F,, 
such that Beh(M ( ., <Prod . a > a€/ , ) = B,. We construct a PS-machine <Af,<Prod /a > /aa€A > 
of interface E such that Beh(M, <Prod /a '>, €/a0 , ) = £ " 1 (fl). 

Let M be defined as follows: 

lnit M = n, € , Inly 

Trans M = {<a . e, £ >: such that <q,, 5,(6), r,> € Trans M for all / € /}. 
It is easy to check that lnit M is nonempty and that <a,KSL> € Trans M for all a € Q M . 
Thus M is a machine. To show that M is an l/O-machine, we must show that it is 
input-cooperative. Suppose a € M and e € ln f . Since 8. preserves input, it follows that 
6,(6) € \n F U {X P } for each / € /. Since each M. is input-cooperative, for each / € / we 
can get r, such that <q p 8,(6), r? € Trans M . It follows that <g , e, £ > € Trans M . 

For each / € /, and a € A,, define 

Prod. a ' = {<fl , e, £ > € Trans M : <q n «,(e), r,> € Prod ia and e t ln £ }. 
It is clear that each Prod. ' is a productive step set for M. To show that 
<M, <Prod /a '> >e/ia€/ , > is a PS- machine, we must show that the sets Prod u ' cover the set 
of nonnull output or X-steps in Trans M .. Suppose <fl , e, £ > is such a step. Then <q jt 
S.(e), r? is a nonnull output or X-step for M. for some /' € /, by the fact that S. strictly 
preserves outputs. Since the collection <Prod, a > a€A covers the nonnull output or 
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X-steps for M n we know that <q jt 8,{e), rf € Prod, a for some a € A.. Hence <fl , e, r > € 

We claim that Beh(M, <Prod, a V.^) = £ • 1 «Beh(M / , <Prod /4 ,> ae ^)> /e ,). 

Case Beh(M, <Prod. a '> /£ , a£ ^) C £ 1 (a ): 

Each computation X of M maps in an obvious way (by taking the image of the 
observation part under 5,, and the canonical projection of the state part) to a 
computation X, of M r for each / € /. Suppose that X is fair. Let / € / and a € A t be fixed. 
We show that if Prod /a is repeatedly enabled in X /t then Prod /a repeatedly runs in X,. 
Suppose Prod. a is repeatedly enabled in X ; . 

We first show that, given a € State w , if Prod /a is enabled in state q n then Prod ta ' is 
enabled in state a • If Prod /a is enabled in state q r then there exists /, € CXit f U [\ F ] and 
r, € Q M such that <q i , ©,, rj> € Prod /a . Since 8 ( . is onto Out fl we we can get e € Out e U 
{X E } with fi^e) = f r By the compatible coupling property of jj , we know that fi y (e) € \n F 
U {X r } for all / € / - {/}. For each / € / - {/}, by the input-cooperative property of M., we 
can get r. ' such that <q., Sj(e), r f *> € Trans M . It follows that <fl , e, £ *> € Prod /a ', and 
thus Prod, . ' is enabled in state o . 

Since Prod. a is repeatedly enabled in X, by hypothesis, and Prod ya enabled in state 
q, implies Prod /a ' enabled in state a , we know that Prod /a ' is repeatedly enabled in X. 
By the fairness of X, it follows that Prod. . ' repeatedly runs in X. By definition of Prod, „ ', 
if Step x (f) € Prod ta ', then Step x (0 € Prod /a . This implies that Prod /a repeatedly runs in 

x r 

Case S. 1 (fi ) C Beh(M, <Prod / a > /€/iaeA/ ): 

Suppose that «.(x) € Beh(M / , <Prod / a \ eA ), for all / € /. For each /' € /, let X, be a fair 
computation of M t in which the observation tyx) is generated. We construct a fair 
computation X for M, such that Obs x = x. 

Without loss of generality we assume that the X, have the following property: For 
all t € [0, oo), if a productive X-step runs at time f in X. for some / € /, then the step that 
runs at time t in X y is null for all / € / - {/}. If we are given a collection <X, > /€/ for which 
this property does not hold, then it is a simple matter to construct order-isomorphisms /.: 
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[0, oo) -♦ [0, oo) such that if X, = X, ' • f r then Obs x = Obs x . for all / and the desired 
property holds for the collection <X,>, e/ . Since the property of being a fair computation 
is preserved under stretching of [0, oo) by an order-isomorphism, it follows that each X, 
is a fair computation for M r 

We now define X by letting Obs x = x and State x (f) = <State x (f )> ;€/ . It is easy to 
see that X is a computation for M. 

To show that X is fair, suppose that Prod /a ' is repeatedly enabled in X. Since 
Prod' enabled in state o implies Prod,, enabled in state q„ it follows that Prod,, is 
repeatedly enabled in X,. Since X, is fair, we know that Prod ia repeatedly runs in X r We 
claim that if Step x (f) € Prod /a then Step x (f) € Prod,, ' as well, and hence Prod 4a ' 
repeatedly runs in X. 

By definition of Prod Aa ', if Step x (f) € Prod /a then Step x (f) € Prod /a ', except in case 
Obs x (f) € ln r But if Obs x (f) € ln(£), then the fact that fi, preserves inputs and Prod ta 
contains only output and X-steps implies that Step x (f) * <q p X, rj> € Prod 4a . Since & is 
injective and preserves inputs, it musl be the case that Obs x (f) € In^ for some/ € / - {/}, 
and hence Step Y (f) is nonnull. This contradicts our assumption that if a productive 
X-step runs at time t in X p then the step occurring at time/ in X y is null for all ;' € / - {/}. I 

5.6 Alternative Classes of Computable Behaviors 

The class of l/O-behaviors is by no means the only class of "computable" 
behaviors that it is interesting to consider. By replacing the fairness requirement for 
computations of l/O-systems with that of "weak fairness," in which a process is 
required to repeatedly run only if it is persistently enabled, rather than repeatedly 
enabled, we obtain the class of weak l/p-behaviors (Wl/O-behaviors). It can be shown 
that every Wl/O-behavior is an l/O-behavior, but not every l/O-behavior is a 
Wl/O-behavior. The notion of Wl/O-consistency is therefore strictly more stringent 
than l/O-consistency. 

Besides the fairness assumption, the definition of the class of l/O-behaviors 
embodies several other choices that might have been made differently: 

(1) (Asynchrony) - The l/O-systems model is an asynchronous model of 
computation. We might have chosen a timing-dependent model of computation instead. 
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(2) {Input/Output Structure) - Instead of focusing on interfaces with 
input/output structure, we might have chosen additional or alternative structure, such 
as interfaces in which events include information about the physical location at which 
they occur. 

(3) (Simultaneity) - The definition of an l/O-system permits at most one 
process to perform an output at any instant of tone. We might imagine a more general 
model in which any number of processes can perform an output at once. 

An interesting avenue for future research is to try to discover additional classes of 
behaviors and associated notions of consistency by modifying one or more of the above 
assumptions. 
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6. A Completeness Result 

A reasonable question to ask about the sufficient correctness conditions required 
by the Correctness Theorem is whether these conditions are also necessary. That is, is 
it the case that the maximality and validity conditions hold for every correct 
implementation involving state-transition specifications? In this chapter we show that in 
general the maximality and validity conditions need not hold for every correct 
implementation. However, it is possible to impose some well-formedness conditions on 
the state-transition specifications involved in the implementation, which are sufficient to 
ensure that correctness implies maximality and validity. The Completeness Theorem 
(Theorem 6.4) is the formal statement of this result. Although Theorem 6.4 is probably 
not the strongest result of this kind it is possible to prove, it nevertheless sheds some 
light on the limitations of the Correctness Theorem, and serves to motivate some 
well-formedness properties of state-transition specifications. 

6.1 Specification Domains 

The statement and proof of Theorem 6.4 depends crucially on the existence of a 
collection of interfaces, behaviors, abstraction maps, and decomposition maps with 
closure properties like those of the l/O-interfaces, l/O-behaviors, l/O-abstraction maps, 
and l/O-decomposition maps defined in Chapter 5. The definition of a "specification 
domain" below summarizes these properties, which seem like fundamental properties 
that are likely to be shared by other interesting models. 

Informally, a specification domain 9 contains four pieces of data: the 
"^-interfaces," the "9-behaviors," the "9-abstraction maps," and the "9-decomposition 
maps." The 9-interfaces are interfaces with structure particular to the domain 9. For 
example, the l/O-interfaces are those whose non-X events are partitioned into input and 
output events. For each 9-interface E, the 9-behaviors of interface E represent a class 
of "realizable" or "computable" behaviors of interface E. Just as the definition of 
l/O-behavior depends upon the input/output structure of an l/O-interface, whether or 
not a behavior of 3-interface E is a 9-behavior of interface E will depend, in general, on 
the particular structure of the interface E. The 9-abstraction and 9-decomposition maps 
represent meaningful ways to abstract and decompose systems modeled by 
9-behaviors. In general, these maps will have certain preservation properties with 
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respect to the particular structure of the interfaces, just as the l/O-abstraction and 
l/O-decomposition maps preserve input/output structure in various ways. 

The definition of a specification domain requires that the class of 3-behaviors be 
closed under the abstraction and composition operators associated with the 
3-abstraction and 3-decomposition maps. In addition to the properties of closure under 
abstraction and composition discussed above, we require a third regularity property of 
the 9-behaviors. This property, called "nondegeneracy," rules out the empty behavior 
as a 3-behavior of any interface. Intutively, the empty behavior does not model any real 
system, since it is always possible to obtain an observation of a real system, even if that 
observation is only the null observation A. 

Definition • A specification domain 9 consists of the following: 

- A class Interfaces^ of interfaces, called the ^-interfaces. 

• For each pair E, D € Interfaces^, a set AbsMaps«|(f , D) of translations from E 
to D, called the set of ^-abstraction maps from E to D. 

- For each pair E, &?#,, where / is a finite index set and £ and each F, are 
elements of Interfacesg, a set DecMapScjfE, £ ) called the set of ^-decomposition maps 
from EtoE. Each element of DecMapSg(£, £ ) is a vector <8^ /€/ , where 5. is a translation 
from E to F r 

■ For each interface E e Interfaces^, a set Behaviorsg(E) of behaviors of 
interface E, called the set of *i-behaviors of interface E. 
In addition, 3 is required to have the following properties: 

(1) (Nondegeneracy) • For all ^-interfaces E, the empty behavior is not in 
BehaviorSg(E). 

(2) (Abstraction Closure) - For all 9-interfaces E, D, if o 6 AbsMapScj(E, D) and 
B € BehaviorScj(E), then a{B) € Behaviors«j(D). 

(3) (Composition Closure) - For all 3-interfaces E, <Fj> l£l , if 1 € DecMapsgfE, 
£) and fi = <8.> l€/ is such that B, € Behaviors^,) for each / € /, then £ 1 (fi ) € 
Behaviorsg(E). I 

A rather simple example of a specification domain is the domain "CSP," where we 
define every interface to be a CSP-interface, every translation o to be a CSP-abstraction 
map, every finite vector fi of translations with a common domain to be a 
CSP-decomposition map, and define the CSP-behaviors of interface E to be exactly 
those behaviors of interface E that are nonempty, asynchronous, and 
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truncation-closed.* We call this specification domain CSP because it is closely related 
to the "trace model" for CSP defined in [Hoare81b]. In that paper, process behaviors 
are modeled by nonempty, prefix-closed subsets of £*, where £ is an alphabet of 
process events. To each nonempty, prefix-closed subset of £•, there naturally 
corresponds a nonempty, asynchronous, and truncation -closed behavior of interface £. 
Thus, for each of Hoare's processes, there is a CSP-behavior that contains the same 
information. Hoare defines operations of parallel composition, concealment, and 
alphabet transformation on processes. Under the natural correspondence described 
above, Hoare's concealment and alphabet transformation operations are special cases 
of the CSP-abstraction operators defined here, and Hoare's parallel composition 
operation is a special case of the CSP-composition operators defined here. Since no 
truncation-closed behavior can satisfy a specification with nontrivial eventuality 
properties, the specification domain CSP is not particularly useful for the analysis of 
such specifications. 

As a consequence of Theorem 5.1, Corollary 5.5, and Theorem 5.10, the 
l/O-interfaces, l/C-behaviors, I/O- abstraction maps, and l/O-decomposition maps also 
define a specification domain, which we call "I/O." 

We can generalize the definition of l/O-consisterjcy to an arbitrary specification 
domain 9. 

Definition - A specification S of 9-interface E is ^-consistent if S(S) n Behaviorscj(E) * 
0. I 

We define relativized notions of interconnection, implementation, and correctness 
with respect to a specification domain 9 as follows: An interconnection 5 is a 
^-interconnection if the interfaces D 3 , £ 3 , and F 3 for each / € / are 9-interfaces, the 
abstraction map a 3 is a 9-abstraction map from E 3 to D 3 , and the decomposition map £ 3 
is a 9-decomposition map from £ 3 to E 5 . An implementation <3, S abs , £ > is a 
^■implementation if 5 is a 9-interconnection. We say that the 9-implementation 



1 . If x is an observation and t € [0, oo), then the t-truncation of x is the observation x ' 
such that x '(t ') = x{t ') for all t ' £ [0, f), and x '{t ') = X for all t ' € [t , oo). A behavior B is 
truncation-closed if whenever x € B and t € [0, oo), then the f-truncation of x is also in B. 
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O, S abs , £ > is ^-correct if a 3 °(£ 3 ) \a ) € %S^r\B j € ^(S^nBehaviorSojfF 3 ) for each / € 
/. 

Every ^-implementation that is correct in the sense of Chapter 2 is also 3-correct, 
and thus the Correctness Theorem can be used to prove 3-correctness. However, in 
general there will be 9-correct implementations that are not correct in the sense of 
Chapter 2. 

Lemma 6.1 - If a 9 -implementation is correct, then it is 9-correct. 

Proof - Suppose <3, S^, <S / > /6/ > is a correct 9-implementation. For each / € /, let 8, be 
an arbitrary 9-behavior of interface F 3 that satisfies S r Let B tSa = a 3 °(£ )' 1 (8_ ). Then 
since 3 is closed under abstraction and composition, it follows that fi abs is a 9-behavior 
of interface O 3 . By the assumption of correctness, B abs satisfies S abs . Since the B ( were 
arbitrary, it follows that <3, S ab8 , £ > is 9-correct. I 

We next define the notion of an "evolutionary" specification domain. Intuitively, if 
an evolutionary specification domain °J contatns a behavior B that models what a system 
S can do starting from time 0, and if we observe S produce a certain prefix of an 
observation over the interval [0, f), then 9 will also contain a "future" behavior 8 ', which 
models what S is capable of doing, starting from time f. Probably any reasonable 
specification domain will be evolutionary (as is the specification domain I/O) although 
this property does not seem quite fundamental enough to be included as part of the 
definition of a specification domain. 

To define the evolutionary property precisely, we require some additional notation. 
If x and y are observations and a € [0, oo), then we write x = a y if x(f) » y(t) for all t € 
[0, a). If 8 is a behavior of interface £, x € Obs(F) is an observation, and t € [0, oo), then 
define the future of 8 with respect to x and t as follows: 

future, ,(8) = {suffix f (y): y£B,y =, x}. 
Intuitively, if a behavior 8 models what a system can do if we begin watching at time t = 
0, then future, f (8) models what the system can do after we have already observed the 
initial segment of x on the interval [0, 0- 
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Definition - A specification domain 3 is evolutionary if, whenever 6 is a 3-behavior of 
3-interface E, x € 8, and / € [0, oo), then future x t (B) is also a 3-behavior of 3-interface E. 
I 

For the remainder of this chapter, we assume that an evolutionary specification 
domain 3 (such as the domain CSP or I/O) has been fixed. 

6.2 Locally ^-Consistent Subset Specifications 

This section introduces the notion of a "locally 9-consistent" subset specification, 
and obtains some properties of such specifications that will be used in the proof of 
Theorem 6.4. Intuitively, local 3-consistency of a subset specification S means that 0(S) 
contains no isolated observations that cannot be realized in some 3-behavior satisfying 
S. 

Definition - A subset specification S of 3-interface E is locally ^-consistent if for all x € 
0(S) there exists a 3-behavior 8 of interface E such that x € B C 0(S). I 

Note that if S is locally 3-consistent, and in addition 0(S) * 0, then S is 3-consistent. 

Lemma 6.2 below states that if the component module specifications in a 
3-implementation are locally 3-consistent, then the necessary and sufficient conditions 
for correctness provided by Lemma 3.1 for implementations involving subset 
specifications, are also necessary and sufficient for 3-correctness. 

Lemma 6.2 - Suppose <5, S abs , <S / > /e/ > is a 3-implementation, where S abs and each S, 
are subset specifications. Suppose that each S t is locally 3-consistent. Then <5, S abs , 
<S,> /€/ > is 3-correct iff a 3 «(£ 3 )- 1 (<0(S,.)> ;£/ ) Q OfS^). 

Proof • => follows directly from Lemma 3.1 and Lemma 6.1, and actually does not 
require the assumption of local 3-consistency. To show < = , suppose <5, S abs , <S j > ie l> is 
3-correct. It suffices to show that if x € Obs(f) is such that sf(x) € 0(S ; ) for each / e /, 
then a 5 (x) € 0(S abs ). Because each 0(S t ) is assumed locally 3-consistent, given x € 
Obs(£) such that sf(x) € 0(S.) for each / € /, then for each / € / there exists a 3-behavior 
B. of interface pf such that sf{x) € S, C 0{S). Thus a 5 (x) € B abB « a 5 »(£ 5 )' 1 (fi ), which is 
a 3-behavior because 3 is closed under abstraction and composition. By the 
assumption of 3-correctness, it follows that e abs C 0(S abg ), and hence a 3 (x) € 0(S abs ). I 
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The proof of Theorem 6.4 requires Lemma 6.3 below, which expresses a special 
property of locally ^-consistent subset specifications in an evolutionary specification 
domain 9. 

Lemma 6.3 - Suppose that 9 is an evolutionary specification domain, and that S is a 
locally °J-consistent subset specification of 9-interface E. Then future, ,(0(S)) contains a 
9-behavior of 3-interface E whenever x € 0(S) and t € [0, oo). 

Proof - The local 3-consistency of S means that, given x € 0(S) there exists a 
9-behavior B of interface E such that x € B C 0(S). Since 3 is evolutionary, it follows 
that future^ f (6) is a 9-behavior contained in future x ,(0(S)). I 

6.3 Well-Formedness Properties of Specifications 

This section defines three properties of state-transition specifications, which are 
used in the statement of Theorem 6.4. These properties are: regularity, 
quasi-determinacy, and orthogonality. The original motivation for these definitions was 
technical, in the sense that they were sufficient to permit the proof of Theorem 6.4 to go 
through. However, it was surprising to find that these properties could be thought of as 
well-formedness properties that should be satisfied by "good" state-transition 
specifications. In a regular state-transition specification, whether or not a computation 
is valid depends only upon the observation that is produced, and not upon the particular 
choice of states, in a quasi-determinate specification, the fact that the state-transition 
relation permits choices between states is inessential, since a choice of state made at 
time t can have no effect on the portion of the observation produced subsequent to time 
t. Orthogonality is related to the correct partitioning of "local" and "global" properties 
between the state-transition relation and the validity conditions of a specification. 

We first consider regularity. Intuitively, the requirement of regularity amounts to 
the assumption that whether a computation is valid does not depend upon the states 
appearing in the computation, but rather only the observation produced. 

Definition - A state-transition specification S = <M, V> is regular if, for all computations 
X and Y of M, if Obs x = Obs^, then X € V iff Y € V. I 
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To motivate the somewhat technical definition of quasi-determinacy, it is 
convenient to first examine the stronger, but more simply defined notion of 
"determinacy." 

Definition - A machine M is determinate if lnit M is a singleton set, and for all q € Q M and 
all e € E M , there is at most one r € Q u such that <q, e, r> € Trans M . A state-transition 
specification S = <M, V> is determinate if M is determinate. I 

A determinate specification is automatically regular, since a determinate 
specification can have at most one computation that produces a given observation. The 
importance of the determinacy property is that each observation generated by a 
determinate machine is produced in exactly one computation of that machine. Thus, if 
S = <M, V> is a determinate specification, x € 0(S), and X is a computation of M with 
Obs x = x, then it is automatically the case that X € V, since no other computation of M 
can produce the observation x. 

To show that the maximality condition holds for a correct implementation, it 
appears lo be necessary to assume that some piopeily similar to deierminacy hoids for 
the abstract module specification. To see why, consider the following example: We are 
attempting to implement an abstract module whose function is to produce a finite 
number of occurrences of a single event e. (Think of a "black box" with a single light 
bulb on top, and let e be an event corresponding to a flash of the light bulb.) This 
module can be specified in two different ways: 

(Determinate): The state set of the specification consists of a single state *. The event 
e is enabled in state *, and obviously cannot produce any state change. The constraint 
that e should appear only finitely many times is captured by the validity condition. 

(Indeterminate): The state set for the specification is the set of natural numbers. Every 
state is an initial state. The event e is enabled in state k iff k * 0, and the occurrence of 
e causes the state to be decremented. Every computation is valid. In this specification, 
the requirement that e occurs only finitely often is captured by the indeterminate choice 
of initial state. 

Let S (kA be the determinate specification and let S ind be the indeterminate specification. 
ClearlyO(S det ) = 0(S ind ). 
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Now consider an interconnection 3 = <a 3 , 6 3 >, where the abstract interface D 3 , the 
single component interface F 3 , and the composite interface E 3 are all the same interface 
{X, e}, and the abstraction map a 3 and the decomposition map S 3 are the identity 
translation. Clearly both of the implementations <3, S^,, S jnd > and O, S jnd , S det > are 
correct. However, the maximality condition does not hold for the implementation 
<J, S. ., S„ .>. To see this, note that any pair <k, *> is an initial state for the composite 

' ind del 

machine, and is hence reachable for that machine. Furthermore, the event e is always 
enabled for the component machine. For maximality to hold, it would have to be the 
case that e is enabled for the abstract machine no matter what the value of k is. But e is 
not enabled for the abstract machine if k = 0. 

In certain situations, for example the transmission line module specification in 
Appendix II, the use of indeterminate specifications is quite natural. However, the 
preceding example shows that unless we are careful, it may not be possible to use the 
Correctness Theorem to prove the correctness of implementations when such a 
specification is used as the specification for the abstract module. 

The proof of the Completeness Theorem actually does not require that the 
abstract module specification S abs be determinate, but rather the somewhat weaker 
assumption that S abs be regular and "quasi-determinate." Intuitively, the set of future 
observations that can be produced by a quasi -determinate machine is independent of 
the choice of states made on the initial segment [0, t]. 

To define quasi-determinacy precisely, we extend to histories the = a notation 
defined above for observations. If X and Y are histories, then we write X = a Y if Obs x (f) 
= a Obs y (0 and State x (f) = State/f) for all r € [0, a) (and hence for all f € [0, a] by the 
properties of state functions). 

Definition - A machine M is quasi-determinate if for all computations X and Y for M, and 
all t € [0, oo), if Obs x = t Obs y , then there exists a computation Z of M such that Z =, X 
and Obs z = Obs y . A state-transition specification S = <M, V> is quasi-determinate if M 
is quasi -determinate. I 

If a state-transition specification is determinate, then it can also be seen to be 
quasi-determinate by choosing Z = V in the above definition. Determinacy implies that 
State z can be defined in exactly one way on the interval [0, f], thus showing that X = , Z. 



120- 



We next consider orthogonality. Intuitively, in an orthogonal specification, every 
computation agrees for an arbitrarily long time with a valid computation. Orthogonality 
is related to the correct partitioning of "local" and "global" properties between the 
state-transition relation and the validity conditions of a specification. Roughly, 
orthogonality means that the validity conditions contain no information that could have 
been expressed by strengthening the machine part of the specification. 

Definition - A state-transition specification S - <M, V> is orthogonal if for all 
computations X of M and all f € [0, oo), there exists Y € Vsuch that X » f y. 

6.4 The Completeness Theorem 

We can now state and prove the Completeness Theorem. 

Theorem 6.4 (Completeness Theorem) - Let 9 be an evolutionary specification domain. 
Suppose that <3, S abs , <S,> /€ ,> is a ^-implementation, where S abs and S, for each / € / are 
state-transition specifications. Suppose that S^ is regular and quasi-determinate, and 
that S / . is orthogonal and locally 9-consistent for each / € /. If <5, S abs , <S,>, € ,> «s 
9-correct then the maximality and validity conditions hold. 

Proof - Suppose that S abs - <W abs , V abs >, and that S, = Of,, V,>, for each /' € /. Let M be 
the composite machine. Note that the assumption that each S. is locally 9-consistent 
together with the assumption of 9-correctness implies, by Lemma 6.2, that 
« 3 -(£V(<0(S,)>, e ,)C0(S abs ). 

{Validity): To see that the validity condition holds, suppose that X is a computation for M, 
such that X (/) € V, for each / € /. Then S 3 (Obs x ) € 0(S,) for each / € /. It therefore follows, 
by the previous paragraph, that a 3 (Obs x ) € OfS^,.). This means that there exists a 
computation X^ of M^, such that X^ € V abs and Obs x = a 3 (Obs x ). Since S ab8 is 
assumed regular, and Obs y (abs) = Obs y , it follows that the computation X (abs) is also 

* *abs 

in V abs , as required. 

(Maximality): To prove maximality, suppose q € Q M is reachable, and that e € E M is such 
that sf(e) is enabled for M. in state w^g), for each / € /. We wish to show that a 3 (e) is 
enabled for M tt)S in state w aba (g). 
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The proof is of necessity somewhat roundabout, since the assumption of 
3-correctness is the only information we have at our disposal concerning the 
relationship between the computations of M abs and those of the M r The idea is as 
follows: We first obtain a computation X of M that arrives at state q at time n, and such 
that no non-X events occur on the interval [n, oo). Let x = Obs x . For each / € /, we can 
modify X w to obtain a computation X, for M n by letting the event sj(e) occur at time n. Of 
course, we do not yet know that we can modify X (abs) in a similar way -- this is what we 
are trying to show. 

We next use the orthogonality assumption on the S, to obtain, for each / € /, a valid 
computation V, that "looks like" X ( . on the initial segment [0, n + 1). Each Y f produces an 
observation y t € 0(S ; ) that looks like sf(x) on the interval [0, n + 1). We do not know that 
there is a single observation y such that y. = &f(y) for all / € /. However, we can use 
Lemma 6.3, plus the composition closure property of the specification domain 3 to 
obtain an observation z such that, for all / € /, &f{z) € 0(S,) and tyz) looks like y, on the 
interval [0, n + 1). 3-correctness implies that a 3 (z) € OfS^). 

Since a*[z) € ©(S^), we can obtain a computation Z aba for M ab& , such that Obs z 

= a 3 (z). Now, event a 5 (e) occurs at time n in Z abs . If we knew that State z (n) = 

» abs (q), then this would show that a 3 (e) is enabled for M atM in state v^Jq). Although it 
need not be the case that State, (n) = v-JLq), the quasi-determinacy of S b lets us 

abs 

replace the [0, n] segment of State, with the corresponding segment of State x (abs), 

abs 

with the result still a computation of M aba . Since State^absKn) = w abs (q), this will 
complete the proof. 

Formally, since q is reachable for M, by definition of reachability there exist 

Q , q r ... . Q„ € Q w and e , e 1 e n _., € E M , such that q € lnit M , q n = q, and <q k , e k , 

q k + ,> € Trans M for all k € {0, 1 n-1 }. 

Let /: Jf -♦ Steps(£ w , Q M ) be defined by: 

'(*) = <9*. e A - Q k + !>. K < k < n 
- <q n , K q n >, otherwise. 
Then / is a history skeleton and by Lemma 3.5 there is a unique history X such that f 
spans X. Let x = Obs x . It is easy to see that X is a computation of M. 
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Since 8?{e) is enabled for M t in state »,(<?), for each / € / we can choose r. € M 
such that <w / (q), 5 ( 5 (e), rj> € Trans M . It follows that for each /' € /, the history X., where X, 

= „X w and 

Obs x (f) = sf{e), forr = n 

= X, for t € (n, oo) 

State x (0 = r r for t € [n, oo) 
is a computation for M.. Let x. = Obs x for each / € /. 

By the assumption that each S, is orthogonal, we can obtain computations Y, € V, 
such that V, * n + 1 X,. Let y, = Obs y . Then y, € 0(S,) and y, = „ + ! * r 

Since each S, is locally ^-consistent, and the the specification domain 9 is 
evolutionary, we can apply Lemma 6.3 to show that future y n+1 (0(S / )) contains a 

9-behavior B t of interface ff for each / € /. Let 8 = (£ 5 )' 1 {fi ). Then since the 
specification domain 9 is closed under composition, it follows that 8 is a 9-behavior of 
interface E 3 . Since 9-behaviors are nonempty by the nondegeneracy property of 9, it 
follows that we can choose an element z ' of B. Let z be the observation defined by the 
properties: 

z(n) = e 

z(t) - X.forf €(n,n + 1) 

suffix n+1 (z) =z\ 
Then by construction, sf(z) € 0(S ; ) for each / € /. As shown in the first paragraph of the 
proof, it follows by 9-correctness that a\z) € ©(S^. 

Since a*(z) € ©(S^, there exists a computation Z tjM for M^ with Obs 2 = 

sbs 

a\z). By construction, Obs 2 = a 3 (z) = n a 3 (x) ■ Obs x (abs). Since S^ is 

ttbs 

quasi-determinate, there exists a computation Z^ ' such that Z ab8 ' = n X (abs) and 
Obs, . = Obs, . Since Z ' * X (ab8) , we know that State, 4n) = w ah8 (q). Since 

abs abs "" *abs m 

a 5 (e) occurs at time n in Z abs ', it follows that a s (e) is enabled for M abs in state w abs (q). as 
desired. I 
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7. Conclusion 
7.1 Summary 

The important accomplishments of this thesis are the following: 

1. Formal Framework - A major accomplishment of this thesis is that it sets 
up a formal framework within which it is possible to formulate precisely a large number 
of interesting and important questions about specifications and correctness proofs, and 
to obtain rigorous answers to these questions. The framework includes the notions of 
interface, observation behavior, composition, and abstraction, as primitive. These 
primitive notions are used to give precise, language- independent definitions of the 
notions of implementation, correctness, and consistency. 

2. State-Transition Specifications • The thesis shows how module 
behaviors can be conveniently and naturally described in terms of a machine that 
generates an observation as it executes, plus some validity conditions on the 
computations of that machine. Specifications stated in such a form lend themselves to 
a systematic method for performing correctness proofs. 

3. Rely- and Guarantee-Conditions - The concept of rely- and 
guarantee-conditions is shown to be useful for organizing eventuality specifications and 
proofs of correctness involving such specifications. The use of rely- and 
guarantee-conditions seems to result in simple proofs based on the communication 
structure of a system, rather than in proofs based on the structure of computations. 

4. Consistency of Specifications - The l/O-behavior model provides an 
interesting and useful notion of consistency for eventuality specifications. The thesis 
obtains a technique for proving the l/O-consistency of state-transition specifications. 

The investigation of state-transition specification performed in this thesis has 
resulted in some practical insights that can be tentatively expressed in the form of the 
following procedure for refinement of an abstract module into a system of component 
modules: 

(1) Determine the interconnection of component modules that will be used to 
implement the abstract module. 

(2) Identify the implementation invariant and the rely-/guarantee-conditions 
required for the proof of correctness. 

(3) "Localize" the rely-/guarantee-conditions to each component module. 
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Introduce sufficient information into the component module states to permit the 
localized conditions to be conveniently expressed. 

(4) Define the state-transition relations for each component module. 

(5) Check the completed component module specifications by proving their 

consistency. 

(6) Use the component module specifications to perform a complete proof of 

correctness for the implementation. 

The resource manager example in Appendix II illustrates the use of this procedure. 

It has unfortunately been possible in this thesis to investigate only a tiny fraction of 
the questions that could conceivably be formulated using the framework developed 
here. The remainder of this chapter lists a number of questions that have not been 
addressed, but should be. Hopefully the answers to these questions can provide further 
practical insights into the problem of design, and ultimately contribute to more useful 
and reliable distributed/concurrent systems. 

7.2 Ideas for Future Work 

The basic framework set up in this thesis can serve as a starting point for a number 
of interesting extensions. The discussion below is concerned with the following broad 
possibilities for investigation: 

(1) Specification Domains 

(2) Semantic Properties of State-Transition Specifications 

(3) Organizing Principles for Specifications and Proofs 

(4) Formal Specification and Proof 

(5) Non -State-Transition Specifications 

7.2.1 Specification Domains 

The concept of a specification domain appears to offer considerable possibilities 
for theoretical investigation. There are two broad directions for future investigation of 
specification domains. The first direction is concerned with developing the general 
theory of specification domains, and relating this theory, to domain theory as used in 
programming language semantics. The second direction is to construct additional 
example specification domains that model systems with interesting properties. 
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Plausible steps toward a general theory of specification domains might include the 

following: 

(1) The definition of a specification domain should be generalized so that the 
particular structure of an observation is not specified. The assumption of the particular 
structure of translations between interfaces would also have to be removed. A 
reasonable approach might be to assume that the interfaces and translations comprise 
the objects and morphisms of a category. The relationship between interfaces and 
observations would take the form of a functor defined on the category of interfaces, 
which maps each interface E to the set Obs(E) of observations over E, and which maps 
each translation a: E -*■ Fto a function on observations. 

(2) The notion of a behavior should be generalized so that a behavior 
determines, but is not identified with, a set of observations. This would permit behaviors 
such as the "futures processes" of [Rounds81] to be used, as well as correspondingly 
more general abstraction and composition operations. There still should be some 
constraints on the effect of abstraction and composition operations with respect to the 
set of observations determined by a behavior. It is not immediately obvious what those 
constraints should be. 

(3) An attempt should be made to try to identify the correct set of regularity 
assumptions for abstraction and composition operations. The results of Chapter 6 
required no such assumptions, however it seems reasonable that the classes of 
abstraction and decomposition maps ought to be closed under function composition 
and include the identity translations. The l/O-abstraction maps and l/O-decomposition 
maps certainly have these properties. 

(4) The specification domain I/O seems to provide motivation for a kind of 
duality between abstraction and decomposition, in the sense that abstraction and 
decomposition maps seem to have complementary preservation properties with respect 
to input and output. It would be very interesting if abstraction and decomposition maps 
could be unified, so that they are just dual instances of a single underlying notion of 
translation, or "interface morphism." One way this might be accomplished is by 
assuming the existence of a kind of conjugation operation on interfaces. Intuitively, the 
conjugate of a module interface would be the interface of the module's environment. 
The duality between abstraction and decomposition might then be captured by stating 
that a decomposition map is an abstraction map defined on conjugate interfaces. 
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To help motivate the correct general definitions, further specific examples of 
specification domains should be constructed and studied. Ideas for constructing 
further examples of specification domains might be as follows: 

(1) Different notions of observation might be used to construct a number of 
interesting specification domains. One example is to replace the assumption that 
observations contain only finitely many events in any finite interval with some less 
restrictive topological assumption, and to attempt to construct corresponding classes of 
behaviors. If the machine approach to defining behaviors is to be used, then there is the 
problem of how to define a machine that permits infinitely many events to occur in a 
finite interval. Examples of such "machines" already appear in the theory of dynamical 
systems. For example, if one is willing to assume that an observation is a continuous, 
differentiable function on [0, oo), then the correct notion of machine is that of a 
differential equation. 

(2) Different special assumptions on behaviors can be made to model systems 
with particular properties. For example, it would be interesting to find a class of 
behaviors that includes non -asynchronous behaviors, corresponding to sets of 
observations that are not necessarily closed under stretching of the time axis. These 
behaviors would model timing-dependent systems. If observations contain space 
coordinates, in addition to time coordinates, then it might be possible to construct a 
class of behaviors with the property that information doesn't travel "too quickly" from 
one place to another. This specification domain could be used to investigate the 
problem of what can be observed by one module about the operation of another in a 
distributed system. Another idea might be to try to characterize a class of "atomic" 
behaviors, like the atomic data types of [Weihl84]. The observations in these behaviors 
would have certain serializability properties. 

(3) An attempt should be made to deal correctly with simultaneity. It should be 

possible to do this within the specification domain framework as follows: Introduce 
additional structure on interfaces to model the intuitive idea that some events represent 
the simultaneous occurrence of more primitive events. For example, it might be 
assumed that the events in an interface form a complete lower semilattice with X at the 
bottom, and with the semilattice operation u representing the operation of 
"simultaneous occurrence." The main problem with this approach is how to introduce 
the notions of input and output so that an assignment of behaviors that is 
nondegenerate and closed under composition can be defined. 
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7.2.2 Semantic Properties of State-Transition Specifications 

In Chapter 6 three semantic properties of state-transition specifications were 
identified (determinacy, regularity, orthogonality) and it was suggested that these might 
be properties characteristic of "well-formed" specifications. The idea of finding 
semantic well-formedness properties of specifications also appears in [Jones81], where 
the notion of an "unbiased" specification is discussed. It is interesting and useful to try 
to identify such properties, since they can possibly serve as guidelines in the design 
process. An important extension to this thesis would be to try to examine more closely 
the properties identified in Chapter 6, to develop techniques for proving that 
specifications have these properties, and to try to develop additional well-formedness 
properties. 

7.2.3 Organizing Principles for Specifications and Proofs 

The development of organizing principles for specifications and proofs appears to 
be a promising area of investigation. The rely- and guarantee-condition approach to 
writing specifications and performing correctness proofs is an example of the kind of 
results one might try to obtain. The way to proceed in this area is to perform example 
specifications and correctness proofs, and then try to abstract from these examples 
something in the way of general methods that would be applicable to other examples. 
This is difficult, because the examples take a long time to do, and it is hard to abstract 
general methods from a few examples. 

Rely-/Guarantee-Conditions: 

Rely- and guarantee-conditions were used in this thesis in the statement of the 
validity condition portion of a specification only. This is in contrast to the work of other 
researchers, for example [Jones81], in which rely- and guarantee-conditions can be 
used for state-transition properties only. For the examples in this thesis it did not seem 
particularly helpful to use rely- and guarantee-conditions for the state-transition portion 
of a specification. One possible exception might be the synchronizer and synchronizer 
component module specifications, in which the use of rely- and guarantee-conditions in 
the state-transition part of the specification might obviate the need for an error state. 
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Determinate vs. Indeterminate Specifications: 

Both determinate and indeterminate specifications seem to be useful. From a 
strictly theoretical standpoint, determinate specifications are more convenient to work 
with than indeterminate specifications. From a practical point of view, though, there are 
cases (such as the transmission line specification of Appendix II) in which the use of 
indeterminate specifications is quite natural, and in which an equivalent determinate 
specification would have to be stated in a much more convoluted fashion. Perhaps a 
result could be proved which shows that determinate and indeterminate specifications 
are equivalent in expressive power, in the sense that every indeterminate specification 
could be stated equivalents as a determinate specification. Such a result would permit 
the theory of specification to deal only with the more convenient determinate 
specifications, while permitting indeterminate specifications to be used in examples 
where they seem natural. 

Parallel Specifications: 

In certain examples, though no! in any of the ones considered in this thesis, it is 
convenient to describe the desired functioning of a module in terms of a collection of 
loosely interacting concurrent processes. This process structure is a logical one used 
for descriptive purposes only, and may or may not bear any relation to the structure of 
an implementation of the module. It would be nice to be able to write specifications that 
reflect such a logical decomposition. State-transition specifications as described in this 
thesis are an inherently sequential form of description, since they include only a single 
machine. Perhaps the state-transition technique could be extended by permitting 
specifications to include a collection of machines that execute in parallel, and whose 
state sets are mostly independent of each other. To perform correctness proofs with 
this kind of specification would require a modified version of the Correctness Theorem. 

Differential vs. Integral Form: 

There is a certain amount of flexibility in whether state-transition properties are 
expressed in -differential," state-transition form, or in "integral," invariant form. In 
general, given a statement of the invariant form, "for all reachable states q, property 
P{q) holds," an equivalent expression in state-transition form can be obtained by a 
simple syntactic transformation analogous to differentiation, e.g. "Property P holds of 



129 



all initial states, and a state transition from q to r can occur only if P(q) implies P{r)." 
There is apparently no general method for "integration," that is, for obtaining equivalent 
statements in invariant form, given a statement in state-transition form. 

In this thesis, the policy was adopted that all local properties would be expressed 
in state-transition form, rather than in invariant form. One reason for this is that, in 
general, invariants for the composite machine for an implementation cannot be proved 
directly from invariants for the component machines. Rather, it is necessary to first 
"differentiate" the invariants for the components, to obtain corresponding 
preconditions for event occurrences, and then use these preconditions in an inductive 
proof of the desired invariant for the composite machine. In certain circumstances, 
though, it seems natural to express specifications in invariant, rather than 
state-transition form. For example, in the synchronizer module specification it is 
perhaps more natural to state explicitly that "at most one user process can be running 
at any instant," rather than the more indirect approach taken here, where we use the 
precondition "a run event can occur only if there are no users currently running." 
Further investigation into the relationship between state-transition and invariant 
specifications seems needed. 

7.2.4 Formal Specification and Proof 

For the specification and proof techniques developed in this thesis to be useful for 
practical examples, the development of mechanical aids for manipulating specifications 
and assisting in correctness proofs is essential. Appendix I takes the first steps toward 
this goal by showing how all of the proof techniques developed in this thesis can be 
formalized within an appropriate temporal language. Further steps should be taken 
along the following lines: 

(1) A practical method should be devised for describing heterogeneous 
algebras and for associating with each description a reasonably powerful, sound 
deductive system for deducing properties of the described algebra. In spite of the large 
amount of work that has been done in this area (specification of abstract data types), a 
completely satisfactory method is still lacking. 

(2) Tools are needed for enumeration and checking of cases in inductive 
proofs of invariance. In the correctness proofs performed in this thesis, once the 
implementation invariant is devised, the proof that it is inductive is a tedious case 
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analysis that ought to be easily mechanizable. 

(3) Mechanical aids for checking proofs in temporal logic are needed. Such a 
proof checker would probably not be capable of performing complete proofs by itself, 
but rather would serve to fill in intermediate steps in a proof generated by a human 
verfier. 

7.2.5 Non-State-Transition Specifications 

It would be interesting to use the framework of definitions set up in Chapter 2 to 
investigate specification languages not based on the state-transition approach. One 
obvious example is to investigate specification languages based on some kind of 
generalized regular expression. Preliminary experience with this kind of specification 
seems to indicate that the regular expression approach seems to produce shorter 
specifications for trivial examples, but for more complex examples it is much more 
difficult to express the desired properties. Interesting questions are what sort of 
deductive system, if any, could be used to derive consequences from specifications 
stated in regular expression form, and what form the Correctness Theorem would take 
for such specifications. 
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Appendix I - Formal Specification and Proof 

The purpose of this appendix is to outline the way in which the informal 
state-transition specification and proof techniques used in this thesis can be formalized, 
perhaps to permit mechanically-assisted specification and verification. The major new 
concepts introduced to permit this formalization are those of an "event/state algebra" 
and an "implementation algebra." An event/state algebra is a heterogeneous algebra 
that embeds the machine part of a state-transition specification. An "implementation 
algebra" is a special kind of event/state algebra, which embeds the composite machine 
for an implementation, and which contains among its operations the abstraction and 
decomposition map for the implementation. 

The utility of event/state algebras and implementation algebras derives from the 
fact that associated with each event/state algebra A (and hence each implementation 
algebra as well) is a temporal logic language 3(A), within which can be expressed 
properties of the computations of the embedded machine. Each of the proof techniques 
presented in this thesis has the property that its hypotheses can be formalized in terms 
of the validity of verification conditions, which are sentences expressed in the temporal 
language of an appropriate event/state algebra. The problem of formalizing proofs that 
use the techniques of this thesis is thereby reduced to the following two problems: 

(1) Find a convenient method for describing event/state algebras. 

(2) Find a general method whereby the description of an event/state algebra A 
can be used to obtain a formal deductive system for deriving a large number of true 
statements about A, where these statements are expressed in the temporal language 
9(A). 

In this appendix, the following tasks are accomplished: 

(1) The notions of event/state algebra and implementation algebra are 
defined. 

(2) Precise semantics are given for the temporal language 9(A) associated with 
an event/state algebra A. 

(3) An approach, based on set theory, for describing event/state algebras is 
sketched. It is indicated how, from the description of an event/state algebra A, an 
A-sound deductive system for the language 3(A) might be obtained. 

(4) It is show how the various proof techniques presented in this thesis can be 
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formalized in the language 3(A) for an appropriate A. 

1.3 Event/State Algebras 

Definition - An event/state algebra A is a heterogeneous algebra whose signature is of 
the form: <Events„, States^,, Init,, Trans,,, \ A , ... >, where X A is a distinguished constant 
of sort Events A so that <Events / ,, \ A > is an interface, and <Events A , States,, Init^, Trans A > 
is a machine, which we call the embedded machine and which we denote by Mach^. I 

When there is only one event/state algebra under consideration, we will omit the 
identifying subscripts. The ellipsis in the signature of A indicates that A is permitted to 
contain additional sorts, relations, and functions besides those explicitly listed. The 
reason for permitting A to contain these additional sorts, relations, and functions, is to 
provide a mechanism by which the temporal language 3(A) can be made as expressive 
as desired. 

We now define precisely the syntax and semantics of the temporal language 9(A) 
of an event/state algebra A. Let 2 A be the signature of A. The signature 2 A is required 
to contain distinguished sorts Events and States. In addition, we assume that 
corresponding to each sort of 2 A is a countably infinite collection of variables which we 
use to range over values of that sort. The language 9(A) contains syntactic categories 
of "terms," "atomic formulas," and "formulas," which are defined by induction as 
follows: 

Terms: 

(1) The distinguished symbols Now and After are terms of sort States. 

(2) The distinguished symbol Occurs is a term of sort Events. 

(3) If v is a variable of sort S, then v is a term of sort S. 

(4) If f n t n are terms of sorts S v ... , S n , respectively, and f is an n-ary 

function symbol of type S, X ... XS n -*S, then f(f 1 ... tj is a term of sort S. 

Atomic Formulas: If ^ t n are terms of sorts S 1 S n , respectively, and R is an n-ary 

relation symbol of type S, X ... x S n , then R(f 1 ... tj is an atomic formula. 

Formulas: 

(1) An atomic formula is a formula. 
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(2) If g> and $ are formulas, and v is a variable of sort S, then -19, «p v ^, and 
(3v€S)<p are formulas. 

(3) If <p is a formula, then D<j> is a formula. 

The sets of terms, atomic formulas, and formulas of S[A) are the least sets with the 
properties listed. 

The first-order language 1(A) is the sublanguage of 9{/\) obtained by omitting 
formation rules (1) and (2) under "Terms," and formation rule (3) under "Formulas." 
We treat the additional logical connectives a, -►,«-*, V as abbreviations in the usual 
way. In addition, the temporal operator is regarded as an abbreviation for -iCJ-i. 

We use the notation f(v 1 ... v n ) to denote a term t whose variables are a subset of 
the set {v v ... , v n ), and the notation <p(v, ... v n ) to denote a formula whose free variables 
are a subset of [v v ... , v n ). The notations t(t,/v^ ... t n /v n ) and ^(f/v, ... t n /v n ) denote 

the result of substituting the terms / 1 t n for free occurrences of the variables v v ... , 

v n in / and <p, respectively. 

Next, we define the semantics of «JT4). If S is a symbol (sort name, function symbol, 
or relation symbol) in the signature of A, then we use S A to represent the denotation (set, 
function, or relation) assigned by A to the symbol S. Define an interpretation for a 
sequence v v ... , v n of variables of sorts S v ... , S n , respectively, to be a sequence a v ... , 
a n of elements of A, where each a k is of sort S k . The semantics of 9(A) are defined in two 
parts. First, given an intepretation a v ... , a n for the free variables v v ... , v n , a term 
f(v 1 .... v n ) of sort S denotes a function t[a,/v A ... a n /vj from Steps(Events A , States^) to 
S A , whose value on the step s = <q, e, r> is defined as follows: 

(1) If t is Now, then t [a, /v, ... a n /v n ](s) = q. 
If t is After, then t[a^/v % ... B n /v^(s) = r. 

(2) If /is Occurs, then ffa/v, ... a n /v n ](s) = e. 

(3) If t is the variable v k , then /[a 1 /v 1 ... a n /v n ](s) = a k . 

(4) If t is Kf, ... f„), then t[a/v^ ... a„/v,l(s) = f A (to 1 ... b„), 
where b k = ^[a/v, ... a n /vj(s) for each *. 

The second part of the definition of the semantics of V(A) is concerned with when a 
formula <p(v, ... v n ) is satisfied by a history X € Hist(Events A , States^), and an 

intepretation a v ... , a n for v 1 v n . We abbreviate this as X N= A f>[a 1 /v 1 ... a p /vj, or, 

when the algebra A is clear from the context, as simply X N* f>[a 1 /v 1 ... a /vj. 
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Atomic Formulas: If 9 is the atomic formula R(f , ... t m ), where the free variables of each 

t k are in the set [v, v„}, then X N yla/v, ... a n /v n ] iff <b y ... , b n > € R A , where b k = 

fja/v, ... a„/v„](Step x (0)) for each k. 

Formulas: If 9 is a formula, but not an atomic formula, then 

(1) If 9 is -'</', ^ v x. or (3v£S)+, then satisfaction for 9 is defined by induction 
in the usual way. 

(2) If 9 is D*, then X N 9[a/v 1 ... a n /v n ] iff suffix,(X) N= rfa/v, ... a n /v n ] for 
all t € [0, 00). 

Suppose that 9(1^ ... v n ) is a formula of <3[A) and that * is a set of formulas of V{A), 
the free variables of which are a subset of {v v ... v n ). We say that 9 is a consequence 
of * in A, written * N A 9, if whenever a v ... , a n is an interpretation for the variables v v 
... , v n , and X € Hist(Events„, States,,) is such that X H tfa/v, ... a n /v n ] for all * in *, 
then X N w[aJv. ... a„/V] as well. The formula 9 is said to be valid in A, abbreviated 
k= A 9, if 9 is a consequence in A of the null set of formulas. A sentence of 9(A) is a 
formula of 1J{A) that has no free variables. If 9 is a sentence and \f> is a formula, then it is 
easily verified that 9 ¥= A $ iff M A 9 -* 4<. 

The following result makes explicit the relationship between the preceding 
definitions and the usual semantics of first/order logic. 

Lemma 1.1 - Suppose that <p{v Q ... v n ) is a formula of 9^4), containing no occurrences of 
□. Suppose that A is an event/state algebra, that X € Hist(Events A , States,), and that 
a v ... , a n is an interpretation for the variables v y ... , v n . Suppose X(0) = <q, e, r>. Then 

X N, rfa/v, ... a n /v n ] 
iff 

t= A vla/v, ... a n /v n , g/Now, e/Occurs, r/ After], 
where the latter is defined in the usual sense of first-order logic. 

Proof - Straightforward. I 

We recall here the definitions, given in Chapter 4, of the sentence Comp of <3[A). 
Comp = Init(Now) a DTrans(Now, Occurs, After) 
Intuitively, X N Comp iff X is a computation for the embedded machine Mach^. 
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We conclude this section with the following definition: Suppose that A is an 
event/state algebra, and Valid is a sentence of 9(A). Then the state-transition 
specification defined by the pair <A, Valid> is the state transition specification S = 
Of, V>, where M = Mach^, and V = {X € Hist(Events A , States^): X *= Comp a Valid}. 

1.4 Description of Event/State Algebras 

In this section, we consider the problem of describing event/state algebras in such 
a way that a sound deductive system for 3(A) can be obtained from a description of the 
event/state algebra A. It should be noted that this problem has already received a good 
deal of attention in the research literature under the heading of "Specification of 
Abstract Data Types." In spite of the effort that has been expended on this problem, 
there still does not seem to be an available description method that is convenient for the 
purposes of this thesis. Hopefully this situation will be rectified in the near future. 

The description technique we use here can be summarized as follows: We assume 
fixed in advance a standard "primitive" or "core" algebra with a sufficiently expressive 
first-order theory. Let C be the core algebra, and let T be its complete first-order theory, 
expressed in the language 1(C). An event/state algebra is described by writing a 
collection of first-order axioms U in an extension I of 1(C), that define an extension by 
definition of T. Such a collection of axioms defines a unique extension of the core 
algebra C to a model A of T U U. 

We wish to obtain an A-sound deductive system for the language 1(A) (= I). 
Since we wish our description method to be powerful enough to describe algebras such 
as Of, 0, 1, +, •>, which cannot be completely axiomatized, it seems unreasonable to 
expect the core theory T to be axiomatizable. If we fix in advance a deductive system 
that axiomatizes a usefully large fragment of T, though, then by augmenting this 
deductive system with the defining axioms U, we can hopefully obtain an axiomatization 
of a usefully large fragment of the complete first-order theory of A. In this thesis, we 
assume as the core theory some suitable variant of the theory of sets. Set theory is 
highly expressive, and this makes it easy to describe desired event/state algebras. 
However, if machine-assisted verification is a goal, then set theory might not be the most 
appropriate: it seems quite possible that some less expressive core theory would be 
more amenable to mechanization. 
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We next consider the problem of deduction in 9(A). Given an event/state algebra 
description, which, as discussed above, we regard as denoting an extension by 
definition of an underlying set theory, we wish to be able to deduce a large class of 
A-valid formulas of 3(A). Suppose we could somehow transform an arbitrary sentence 9 
of 9(A) into a sentence 9 ' of 1(A) such that N= 4 9 *♦ 9 '. In other words, suppose that 
we could axiomatize the temporal operator D and special symbols Now, Occurs, and 
After, in terms of the set theoretic notions of JL. Then the problem of showing )f= a 9, 
where 9 € C J[A), would be reduced to the problem of showing that T t= 9 ', where 9 ' € 
1(A) is the transformed version of 9. 

It seems likely that the reduction described the preceding paragraph can actually 
be carried out, since the idea seems essentially the same as that used in the proofs 
[Harel78] of the "arithmetic completeness" of deductive systems for dynamic logics. 
Assuming that this idea works for the temporal logics 9(A), this would give us a way of 
deducing all valid formulas of 9(A), assuming we have available the complete theory of 
some model of set theory. Although we can never obtain a complete axiomatization of 
set theory, it seems likely that any of the usual collections of axioms for set theory would 
provide us with a deductive system for 9(A) that is powerful enough to be useful In 
practice. 

In practice, to write down explicitly the collection of defining axioms that describe 
an event/state algebra A is cumbersome. It is convenient to introduce some notation 
for common constructions. We do this with the understanding that descriptions 
expressed in this notation stand for collections of first-order defining axioms. In 
general, the description of an event/state algebra can be divided into two parts: one, 
the definition of new sorts, and two, the definition of new function and relation symbols. 

We define new sorts by a set of defining equations that define the new sorts in 
terms of more primitive components. These equations take the form: 

S = 8(S, S n ), 

where S is the new sort being defined, S, S„ are the names of previously-defined 

sorts, and 8 is an expression within which various set-theoretic constructions can 
appear. These defining equations are analogous to the domain equations used in the 
denotational definition of the semantics of a programming language [Gordon79]; 
however, to ensure that a set of equations can be regarded as denoting a colletion of 
defining axioms, we do not permit here the use of recursive equations. The 
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set-theoretic constructions (cartesian product, disjoint union, etc.) that appear on the 
right-hand sides of the defining equations introduce implicitly various "built-in" 
functions and relations (projection, injection, etc.). The constructions we use, and their 
associated built-in functions and relations are listed below. 

Once the equations that define the new sorts have been given, we can use these 
sorts and their built-in function and relations to define additional functions and 
relations, in particular the initial state and state-transition relations for the embedded 
machine. These additional functions and relations are defined by writing defining 
axioms in the usual way. 

1.4.1 Set-Theoretic Constructions Used in Defining Equations 

1. (Enumeration) - The expression {a v ... , a n } denotes the n-element set 
whose elements are the constants a v ... , a n . 

2. (Disjoint Union) - If A and B are sets, then the expression [t A : A + f fl : B] 
denotes the disjoint union D of the sets A and S. The tags t A and t B are used to denote 
the injection operations associated with the disjoint union. That is, if a € A and b £ B, 
then t A :a denotes the image of a, and t B :b the image of b, in D. 

3. (Cartesian Product) - The expression [t A : A X t B : B] denotes the cartesian 
product C of the sets A and S. Associated with an element c of C are its projections c(t A ) 
and c{t B ) onto the sets A and S, respectively. Given a € A and b € S, then the expression 
<t A : a, t B : b> denotes the ordered pair with components a and b. If c € C and a € A, then 
the notation c[a/t A ] denotes the element c ' of C which is identical to c except that its t A 
component has the value a. To reduce clutter in expressions, tags will be omitted from 
both the disjoint union and cartesian product constructions when this is unlikely to 
cause confusion as to the intended meaning. 

4. (Function Space) - If A and B are sets, then the notation [A -* B] denotes 
the set of all functions with domain A and range 8. We use the usual notation f(a) for the 
application of / to the argument a, and the notation f[b/a] for the function that is 
identical to / except that it has value b for argument a. 

5. (Finite Powerset) • The notation Set[A] denotes the set of all finite subsets 
of the set -A. If s € Set[A] and a € A, then the expression a£s is true iff a is an element of 
the set s. The expression |s| denotes the cardinality of the set s. We also use the usual 
operations U, n, and ~ on Set[A]. The notation MSet[A] denotes the set of all finite 
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multisets of elements of -A. We use the same notation for operations on multisets as for 
sets, however, the meaning appropriate for multisets is assumed in this case. 

6. (Finite Sequences) - The notation Seq[A] denotes the set of all finite 
sequences (i.e. strings) of elements of A. If u, v € Seq[A], then \u\ denotes the length of 
u, uv and wv denote the concatenation of u and v, and if n € Nat, then u{n) denotes the 
n + 1st element of u. 

1.4.2 Definition of the State-Transition Relation 

Manipulation of the state-transition relation is sometimes more convenient if its 
defining axioms are factored into a collection of pairs, each of which consists of a 
precondition, and a next-state predicate. The precondition defines the class of events 
to which the pair applies, and defines conditions on the current state that must be 
satisfied before an event in that class can occur. The next-state predicate determines 
the relation that must hold between the current state and the new state that results from 
an occurrence of such an event. 

Although the basic idea of precondition/next-state predicate pairs is fairly simple, 
some subtleties arise in actual use, especially associated with the interpretation of free 
variables common to the two predicates. This problem is similar to that which arises in 
the interpretation of free variables in the pre- and post-conditions used to specify 
sequential programs. We must therefore be somewhat more careful about the precise 
form and meaning of the pairs. A pair takes the form: <Pre(q, ©, x. ). Next(q, r, * )>. where 
e is a variable of sort Events, q and r are variables of sort States, and x is a vector of free 
variables of sorts £ , where £ can be chosen arbitrarily for each pair. A finite collection 
<Pre 1 , Next^, ... , <Pre n , Next n >, where the *th pair contains free variables x. k of sorts 
£ , determines the defining axiom for the state transition relation Trans according to the 
following definition: 

Trans(q, e, r) s V£ =0 (3* A €£ k )(Pre k (q, e, a A ) a Next„(g, r, * „)), 
where Pre (q, e, * ^ s e = X and Next (g, r.zjsr = q. What the above definition 
says is that a step <q, e, r> satisfies the state transition relation Trans iff there exists a 
pair <Pre„, Next„> (0 < * < n), and an interpretation of the free variables of that pair, 
such that the precondition and next state predicate hold for that pair. 
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A useful convention we will follow, which simplifies the maximally part of 
correctness proofs, is to define the preconditions Pre(q, e, & ) and next state predicate 
Next(q, r, x ) in each pair so that they satisfy the following relationship: 

»= (VqeStates, e€Events, x €3. ){Pre(q, e, x ) - (3r€States)Next(q, r, xj). 
That is, whenever the precondition is satisfied by a state q, an event e, and an 
interpretation x for the free variables, then there must be a new state r such that q, r and 
x_ satisfy the next state predicate. 

1.4.3 Parameterized Descriptions 

Quite often one wishes to write parameterized descriptions of event/state 
algebras, where the parameters may be values, as in the case of the synchronizer 
component module, where the number of initial tokens is given as a parameter, or 
perhaps sets or some other kind of object. In this thesis, we view a parameterized 
event/state algebra description as a schema for the construction of a family of related 
descriptions. This way of treating parameters is satisfactory as long as there is no need 
to perform reasoning about parameters with infinitary structure. A more general 
treatement of parameters requires extensions to the event/state algebra formalism, and 
is outside the scope of this thesis. 

1.5 Implementation Algebras 

We have previously discussed the notion of an event/state algebra, which is a 
formal structure that embeds the machine part of a state-transition specification. The 
purpose of an event/state algebra is to provide semantics for the associated temporal 
language. The temporal language, in turn, serves as a vehicle for the formal statement 
of properties of histories, among which are the validity conditions for a specification. 
Augmented with a sound deductive system, the temporal language can also serve to 
express derivations of consequences of a specification. 

Just as we can use the temporal language associated with a specification to 
express and derive consequences of that specification, we would like to associate with 
an implementation a language suitable for the expression and derivation of the 
conditions required for the correctness of that implementation. However, taken 
separately, none of the temporal languages associated with any of the modules involved 
in an implementation suffices for this purpose. To solve this problem, we define below 
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the notion of an "implementation algebra," which is a kind of "composite" event/state 
algebra whose associated temporal language is powerful enough to permit the 
expression of correctness conditions. 

Let us say that an algebra A embeds an algebra B if there exists a signature 
morphism 1 t from the signature of 8 to the signature of A such that, for each sort S 
(resp. function symbol f, relation symbol R) of B, the interpretation of S (resp. /, R) in B is 
the same as the interpretation of i(S) (resp. i(f), t(R)) in A. If A embeds B, then since we 
might as well think of B as a subalgebra of A, we will omit mention of the signature 
morphism t when no confusion can arise. 

Suppose A abs is an event/state algebra (corresponding to an abstract module to 
be implemented), and let A = <A V ... , A n > be a finite-length vector of event/state 
algebras (corresponding to the component modules). 

Definition - An implementation algebra for A ab8 and A, is an event state algebra A with 
the following properties: 

(1) A embeds A ab& and each A ; , with 1 < / < n. For each soi t of operation S of 
A abs (resp. A), we write S abs (resp. S') for the corresponding sort or operation of A. 

(2) A contains distinguished functions 

a: Events -► Events abs 

Sf. Events -* Events', for 1 < / < n 

w abs : States - States abs 

w,: States -♦ States', for 1 £ / £ n, 

such that: S A = <o, & > is an interconnection, called the embedded interconnection, 
Mach. is the composite machine for 3 A , Mach A and <Mach A >"_,; and w abg and the m j 

abs / 

are the canonical projections from the cartesian product States to the factors States** 3 
and States', respectively. I 



1. A function, mapping each sort, function symbol, and relation symbol of the signature 
of B to a corresponding sort, function, symbol, or relation symbol of the signature of A, 
that preserves relevant structure such as the -arity of the symbols. 
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Since an implementation algebra is a particular kind of event/state algebra, it has 
an associated temporal language. Furthermore, the temporal language *S[A) associated 
with an implementation algebra A contains the temporal languages 9{/l abs ) and each 
9{/\.) as sublanguages. This property is what makes an implementation algebra useful 
for expressing correctness conditions. 

The description of an implementation algebra is performed in the same way as for 
ordinary event/state algebras. The meanings of many the symbols are fixed by the 
definition of an implementation algebra, and in practice it is convenient to omit their 
defining axioms. For example, the definition of the sort States is fixed by the 
requirement that it be the cartesian product of the sorts States*: 

States = [ir abs : States abs X »,: States 1 X ... X v n : States"]. 
Other examples of symbols whose meanings are fixed by the definition of an 
implementation algebra are the initial state relation Init, and state-transition relation 
Trans for the composite machine. Definitions must always be explicitly given for the sort 
Events, the abstraction map a and the components 6. of the decomposition map. 

I.6 Proof Techniques 

1.6.1 Formal Correctness Theorem 

In this section we reduce the problem of proving the correctness of an 
implementation to the problem of showing the validity of a set of verification conditions, 
which are expressed in the temporal language associated with the implementation 
algebra. There are three verification conditions in the technique introduced here. The 
"invariance" verification condition expresses that the predicate /nv is an 
implementation invariant. The "maximality" verification is a straightforward 
formalization of the the maximality condition required by the Correctness Theorem, 
except that the phrase "q is reachable for the composite machine" is replaced by 
"lnv{q) holds." The "validity" verification condition is the formalization of the validity 
condition required by the Correctness Theorem. 

Recall that the validity condition required by the Correctness Theorem states that, 
if X is a computation for the composite machine that projects, under the canonical 
projections associated with the composite machine, to a valid computation for each 
component machine, then X projects to a valid computation for the abstract machine as 
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well. This condition cannot be formalized directly as a sentence in the temporal 
language of the implementation algebra, since that language has no constructs for 
dealing directly with histories and functions on histories. However, the language does 
contain the function symbols a, <S / >. €/ , w^, and <w,.> € ,, which denote the abstraction 
map, components of the decomposition map, and canonical projections on the state 
set, respectively. 

To formalize the validity verification condition, we need some way of taking the 
sentences that express the conditions required for a computation of the abstract 
machine or a component machine to be valid, and "lifting" these sentences to 
sentences that express the corresponding properties on computations of the composite 
machine. In Chapter 4 we defined a syntactic translation that accomplished this lifting 
in the case of the synchronizer implementation. We now define this translation in 
general, and state a lemma that summarizes its useful properties. 

Suppose that A is an implementation algebra for A ab8 and <A,> /€/ . Given a formula 
9 of ^A abs ), define |fo]| abs to be the formula of <J{A) obtained by replacing each 
occurrence of the symbol Now by the term w^Now), each occurrence of After by the 
term v . (After), and each occurrence of Occurs by the term a(Occurs). Similarly, for 
each / C /, given a formula 9 of 91A,), define fa], be the formula of 9(A) obtained by 
replacing each occurrence of Now by w.(Now), each occurrence of After by w,(After), 
and each occurrence of Occurs by S^Occurs). 

The precise relationship between a formula and its translation is captured by 
Lemma I.2 below. An analogous result is stated in [Wolper82], where process of 
"lifting" specifications of processes to obtain specifications of a system of processes is 
called "relativization." 

Lemma 1.2 (Translation Lemma) ■ Suppose that A is an implementation algebra for A abs 
and <A>, e/ . Suppose that <p(v ... v m ) is a formula of ^A^) (resp. 9(A.), for some / € /), 

that a , ... , a m is an interpretation of the variables v Q v m , and that X is a history over 

Events A and States A . Then 

* >-A IIvWVo - a J v J iff x(abs) >" v, "rfV'o - VJ- 

(resp. X N„ M,[a<Ao - a J v J iff xW N * y ^c/'o - a J v J^ 

Proof ■ Straightforward induction on formulas, based on the precise syntax and 
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semantics of "3(A) given above. I 

In the sequel, to make formulas in the language W of an implementation algebra 
A easier to read, we will often abbreviate the application of the functions w abg , and « A to 
a variable or constant by simply affixing an appropriate subscript to that variable or 
constant. Thus, if q is a variable of sort States, then o abs and q k abbreviate » abs (q) and 
rr k {q), respectively. 

We can now give a formalized version of the Correctness Theorem. Roughly 
speaking, this result says that to prove the correctness of an implementation defined by 
an implementation algebra A, it suffices to perform the following three steps: 

(1) Determine the implementation invariant lnv(q) expressed in the first-order 
language 1(A) and containing the single free variable q of sort States. Show the validity 
of two sentences of 1(A), which assert that Inv is inductive. 

(2) Show the validity of a sentence of 1(A) which implies that the maximality 
condition holds. This sentence is obtained by formalizing the maximality condition of 
the Correctness Theorem in the obvious way. 

(3) Show the validity of a sentence of 9(A) that asserts that the validity 
condition holds. This sentence is formed from the sentences that describe the sets of 
valid computations for the abstract and component machines, through the use of the 
translation operation discussed above. 

Lemma 1.2 (Formal Correctness Theorem) ■ Suppose that A is an implementation 
algebra for A ab8 and <A,> /€ ,. Suppose that Valid abs is a sentence of 9{A abs ), and for each 
/, Valid,, is a sentence of 3(/\.). Let S^ be the state-transition specification defined by 
the pair KA^, Valid^, and for each /', let S, be the state-transition specification defined 
by the pair CA,, Valid^. Suppose that lnv(q) is a formula of 1(A), with one free variable q 
of sort States, such that the verification conditions below hold. Then <3 A , S abs , £ > is 
correct. 

(Invariance): 

(Basis) N (Vg€States)(lnit(g) - lnv(g)) 

(Induction) N (Vq,r€States, e€Events)(Trans(g, e, r) -► (lnv(g) -► lnv(r))) 

(Maximality): 

N (Vq€States, e€Events)((lnv(g) a A /€/ Enabled,.(q, e)) -♦ Enabled abs (g, e)). 

(Validity): 
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Comp N (A. € , BValid^) -> IValid^J,^. 

where 

Enabled abs (q, e) s (3r€States)Trans abs (g abs , a(e), r^) 
Enabled^, e) s preStatesJTrans'Cg,, *,(e), r,). 

Proof - The basis part of the invariance verification condition states that Inv is true for 
all initial states, and the induction part of the invariance verification condition states that 
Inv is preserved under state transitions, and hence the truth of these two conditions 
implies that Inv is inductive. 

From the definition of the predicates Enabled^ and Enabled,, we know that 
Enabled u (q, e) is true of a state q and event e iff o(e) is enabled for Mach A in state 
<W and similar| y- Enabled,(q, e) is true iff «,(e) is enabled for Mach A/ in state q r The 
maximality verification condition therefore says that whenever q is a state such that 
lnv(q) holds, and 8,(e) is enabled for Mach A in state g, for each / with 1 < / < n, then a(e) 
is enabled for Mach A in state q^. This implies the maximality condition required by 

Abs 

the Correctness Theorem. 

By the Translation Lemma, we know that IValid abs I abs is satisfied by a computation 
X of Mach A iff Valid^ is satisfied by the computation X {abs) of M ac h A ab8 ' Similarly, for 
each / we know that fValid,!,. is satisfied by a computation X of Mach^ iff Valid,, is satisfied 
by the computation X w of Mach A . Since a history X satisfies Comp iff X is a computation 
of Mach.. we see that the validity verification condition is the formal statement of the 
validity condition required by the Correctness Theorem. 

Since the truth of the verification conditions above implies that the hypotheses of 
the Correctness Theorem are satisfied, an application of the Correctness Theorem 
shows the correctness of the implementation <3 A , S^, S >. ■ 

1.7 Rely-/Guarantee-Condition Proof Techniques 

In this section we give the formalized versions of the rely- /guarantee-condition 
proof techniques stated in Chapter 3. The first result formalizes Lemma 3.1 1 . 

Corollary 1.4 (Formal Rely/Guarantee Technique I) - Suppose that A is an 
implementation algebra for A ab9 and <A t > ier Suppose that Valid^ m Rely abs - Guar abs 
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is a sentence of <3[A abs ) and that Valid, = Rely, - Guar, for each / € / is a sentence of 
g(A,). Suppose that 

(1 ) Comp N ( A, € , IGuar,!,) - RGuar a J abs , and 

(2) There exists a well-founded partial order < on / such that for all /' € /, 

Comp N JRely a J abs a (A /<( . QGuar,]].) -+ &Rely,l,. 
Then Comp N (A. £/ fiValid,]),) - |[Valid abs l abs . 

Proof - Straightforward from Lemma 3.1 1 . I 
The next result formalizes Lemma 3.12. 

Corollary 1.5 (Formal Rely/Guarantee Technique II) • Suppose that A is an 
implementation algebra for A^ and <A? ja . Suppose that Valid abs s Rely abs - Guar abs 
is a sentence of 3(A ab8 ) and that Valid. = Rely,. -♦ Guar, for each / C / is a sentence of 
«J(>A,). Suppose that for each /', / € / U {abs}, we have determined a sentence RG^. of 
3(A), such that properties (l)-(3) below hold. 

(D(a) Comp l= |Rely a J abs - A y€ , RG absJ 
(b) Comp N A. € , RG, abs - IGuar a J ab8 
(2)(a) Comp N RG ab8 , a A, €/+{abs) RG,, - IRely^., for all; € / 
(b) Comp 1= IGuarJ. - RG, ^ A A /€/+{ab8} RG,, for all / € / 

(3) (Acyclicity) - Whenever {</,, i 2 >, <i 2 , i^ </„, /„ + ,>} is a cycle of /, then 

Comp t= vj?- 1 , RG. , . 
Then Comp N (A, € , [Valid,!,) - IValid a J ate . 

Proof - Straightforward from Lemma 3.12. I 

I.8 l/O-Consistency Proof Technique 

The result below formalizes the technique for proving l/O-consistency expressed 
by Corollary 5.8. 

Corollary 1.6 ■ Suppose that S is the state-transition specification of l/O-interface E 
defined by the pair <A, Valid>, where the sets of inputs and outputs of E are defined by 
the unary relations In and Out of type Events in A. Suppose that the event/state algebra 
A includes among its operations the finite collection of relations <Prod,> /€/ , where Prod, 
is of type States X Events X States. If the following sentences of 9(A) are valid, then S is 



- 151 - 



«J 2 -consistent. 



where 



(1) n= A ;e/ (Vq ,r€States, e€Events)(Prod,(q, e, r) -♦ Trans(q, e, r)) 

(2) N (Vq€States, e€Events)(ln(e) -► (3r€States)Trans(q, e, r» 

(3) t= (Vq,r€States, e€Events)(Trans(q, e, r) a (Out(e) v e ■ X) -»• 

V /€/ Prod,(q, e, r)) 

(4) Comp N= (A /€/ Fair,) - Valid, 



Fair, 



= DOEnabled.(Now) -»• DOProd,(Now, Occurs, After). 



Enabled^q) h (3r€States, e€Events) Prod,(q, e, r) 

Proof - Straightforward from Corollary 5.8. Hypothesis (1) says that the Prod, are 
subsets of Trans. Hypotheses (2) states that Mach„ is input-cooperative. Hypothesis (3) 
states that the Prod fc cover the set of nonnull output or X-steps in Trans. Hypothesis (4) 
formalizes the requirement that every fair computation of Mach^ is valid. I 
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Appendix II - Additional Examples 

In this appendix the specification and' verification techniques introduced in the 
thesis will be further illustrated through two additional examples. The first example 
concerns the specification and implementation of a resource manager module whose 
function is to allocate resources in response to requests from user processes. The 
resource manager is implemented in a highly distributed fashion by a tree-structured 
system of local resource manager modules that communicate with each other to 
determine where resources should be sent. In the second example, a reliable message 
transmission service is specified, and an implementation by an unreliable message 
transmission substrate is given. Reliability is achieved through the use of a 
fault-tolerant protocol: the alternating bit protocol [Bartlette9]. The alternating bit 
protocol example has been examined by several other researchers [Chen82, 
Hailpern80, Lamport83, Schwartz81], and has become somewhat of a standard for 
evaluating specification and verification techniques for concurrent systems. 

The major purpose of the additional examples given here is to lend support to the 
following assertion: Essentially the same techniques as were used to obtain 
specifications and a correctness proof for the synchronizer implementation, can be 
applied in a reasonably systematic way to achieve similar results on other nontrivial 
examples. Thus, the ideas of state-transition specification, rely- and 
guarantee-conditions, and the proof technique embodied in the Correctness Theorem, 
are not ad hoc concepts useful for a single example, but serve as generally applicable 
guiding principles. 

A second point illustrated by the examples of this chapter is that more elegant 
specifications can result if one first imagines the structure of a proof of correctness in 
which the specifications will be used, and then derives the module specifications in an 
attempt to satisfy the requirements imposed by the proof structure. The difference 
between specifications obtained via this approach and those resulting from the "specify 
first, prove later" approach can be seen by comparing the validity conditions given here 
for the send and receive protocol modules with the liveness properties given by Lamport 
[Lamport83] for these modules. The specifications and proof given below are to a large 
extent independent of the precise assumptions on the behavior of the unreliable 
transmission medium. Lamport's presentation does not make this independence quite 
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so explicit. 

The observation that a proof of correctness can be used to derive component 
module specifications suggests the following general method for designing a correct 
implementation of a given abstract module: 

(1) Decide on the communication structure of the system of component 
modules (e.g. tree or ring structure). 

(2) For each pair of component modules that can possibly communicate, 
express informally the properties that each relies on/guarantees to the other to provide. 
These rely- and guarantee-conditions will serve to "cut" the interdependence of the 
component modules in a fashion similar to the way in which a loop invariant cuts the 
dependence of one iteration on preceding and succeeding iterations. 

(3) Select event and state sets for the component modules in such a way that 
the temporal language of the resulting implementation algebra is powerful enough to 
formally express the informally stated rely- and guarantee-conditions. 

(4) "Localize" the rely- and guarantee-conditions so that they are expressed in 
the temporal language of each component module event/state algebra. The rely- and 
guarantee-conditions of a resulting component module specification will be the 
conjunction of the localized rely- and guarantee-conditions, respectively. 

The examples in this appendix will be presented using the notation of Appendix I. 
11.9 A Distributed Resource Management Algorithm 

In this section, we consider the specification and implementation of a resource 
manager module RM, whose function is to allocate resources to a set of clients in 
response to requests from those clients. We will see how the resource manager can be 
implemented by a tree-structured network of local resource manager (LRM) modules, 
each of which communicates with a single client. Initially each local resource manager 
starts out with some subset of the resources. As client requests arrive and are filled at a 
particular site, though, the locally available set of resources might be exhausted. An 
LRM that is deficient in resources must then attempt to obtain additional resources from 
other sites. The interesting part of the implementation is concerned with how the local 
resource managers communicate with each other to determine where the resources 
should be sent. The strategy by which this is accomplished is essentially the 
"DYNAMIC-MATCH" strategy of [Fischer83], although this stategy is explained here in a 
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slightly different and hopefully simpler way than in that paper. 

The resource manager example is presented here as a nontrivial exercise in the 
use of rely- /guarantee-conditions and an associated correctness argument as a basis 
for the derivation of specifications for the local resource manager modules. The use of 
rely- /guarantee-conditions as a guiding principle permits us to derive, in a reasonably 
systematic fashion, essentially the same specification for the local resource manager 
module as the node algorithm presented in [Fischer83]. The primary difference 
between the specification derived here and the algorithm of [Fischer83] is that we are 
not concerned here with the way in which an LRM resolves choices as to the pattern in 
which excess requests are forwarded to its neighbors. In [Fischer83], it is assumed that 
choices are resolved according to a specific probability distribution, and a large portion 
of the paper is concerned with probabilistic analysis of the consequences of this 
assumption. Here we concern ourselves only with showing that every request from a 
client is eventually satisfied, if possible. The argument provided in [Fischer83] of this 
basic correctness property is more of a proof sketch than a proof, and is somewhat 
unsatisfactory for this reason. 

11.9.1 Specification of the Resource Manager Module 

The function of the resource manager module RM can be described as follows: Let 
Clients be a set that contains the names of the clients with which the resource manager 
communicates, and let Resources be a set that contains the names of the resources to 
be managed. A client c requests a resource from the resource manager by issuing a 
request event request*. The resource manager allocates a resource r to client c by 
issuing a reply event reply:<c, r>. In this example, a resource that has been allocated to 
a client is never returned to the resource manager. 

The state of the resource manager can be thought of as consisting of a pair 
<pending, free>, where pending is a multiset of clients that represents the collection of 
unfilled requests and free is the set of available resources. The pending component is a 
multiset since we permit more than one request from a single client to be outstanding at 
one time. Receipt of a request from client c by the resource manager causes an 
instance of c to be added to the pending multiset. The event replyXc, r> can occur only 
if the client c is in the pending multiset and the resource r is in the free set. Occurrence 
of this event causes an instance of c to be removed from the pending set and the 
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resource r to be removed from the free set. It is clear from this description that no 
resource is allocated more than once and no more than one resource is allocated in 
response to each request. In addition, we would like the resource manager to respond 
eventually to every request, as long as the set of free resources has not been exhausted. 

To derive a more precise specification from the preceding informal description, we 
begin by defining the resource manager event/state algebra. Our description has the 
following as parameters: 

Clients: a finite set of clients 

Resources: a finite set of resources 
The interface of the resource manager is defined as follows: 

Events RM = {X} + [request: Clients + reply: (Clients X Resources)]. 

In™* = {X} + [request: Clients] 

Out * 4 = {X} + [reply: (Clients x Resources)] 
The state set for the resource manager is defined by: 

States™ = [free: Set[Resources] X pending: MSet[Clients]]. 

In an initial state, the multiset of pending requests is empty, and all resources are 

free. 

lnit RM (g) s g(free) = Resources a g(pending) * 0. 

The state-transition relation Trans™ is defined by precondition/next-state 
predicate pairs as follows: 

A request event for client c can occur at any time, and causes c to be added to the 

pending set. 

(request) Pre request^' e « c * = e = re0 « uest:c 

Next request (g, r, c) m r = q[(g(pending)U{c))/pending] 

A reply event with resource res for client c can occur only if res is in the free set and c is 
in the pending multiset. It causes res to be removed from the free set and an instance of 
c to be removed from the pending multiset. 

(reply) Pre repiy^' e > c « res ) s e = re P ,v:<c ' res> A c € 9(P8nding) A 

res € q(free) 
Next rep|y {g, r, c, res) s r = q[(q(pending)-{c})/pending ) 

(g(free)-{res))/free] 
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The validity conditions for the resource manager module can be stated in 
rely- /guarantee-condition form as follows: Valid RM s Rely™ - Guar™, where 
Rely RM s □<|Now(free)| > |Now(pending)|) 
Guar RM = D(VceClients)(c € Now(pending) -»■ 

0(3r€Resources)(Occurs = reply:<c, r>)). 
Thus, if the number of outstanding requests never exceeds the number of available 
resources, then the resource manager module guarantees that every request will 
eventually receive a reply. 

11.9.2 Implementation of the Resource Manager 

Our plan is to implement the resource manager module by a tree-structured 
network of local resource manager modules as depicted in Figure 3. Each local 
resource manager is responsible for filling requests originating from a single client. If 
the set of resources locally available is exhausted, the the LRM must try to obtain 
additional resources from elsewhere in the system. If an LRM has a surplus of 
resources, then it must be willing to give "out resources to other LRM's whose resources 
have already been allocated. 

To guide us in our derivation of the components that will be needed as part of an 
LRM state, let us first obtain a rough statement of the validity conditions that an LRM is 
to satisfy. We organize these conditions into properties the LRM relies on its 
environment to provide, and properties that an LRM guarantees to its environment in 
return. An LRM relies on: 

(1 ) No special properties on the part of the client. 

(2) The eventual elimination of resource debts owed to the LRM by its parent. 

(3) The eventual elimination of resource debts owed to the LRM by each of its 
children. 

In return for these properties, an LRM guarantees that: 

(1) Every client request eventually receives a reply. 

(2) Resource debts owed by the LRM to its parent will eventually be eliminated. 

(3) Resource debts owed by the LRM to each of its children will eventually be 
eliminated. 
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Fig. 3. Resource Manager Implementation 
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To obtain formal statements Of the preceding conditions, we must first obtain a 
precise definition of the notion of an LRM having a "resource debt" to one of its 
neighbors, and we must describe the mechanics of how such debts are incurred and 
eliminated. The introduction of the various components of the LRM state below can be 
viewed as providing us with enough expressive power in the language fRA 1 * 9 *) of the 
LRM event/state algebra, to permit the formalization of the undefined quantities in the 
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above statement of the LRM validity conditions. 

A significant feature of the validity conditions stated above is the complementary 
form of the rely- and guarantee-conditions. The conditions above have been selected in 
such a way that ultimately, in the resource manager implementation, the conditions 
relied upon by an LRM / from its neighboring LRM y will be precisely the conditions that 
LRM / guarantees to provide to LRM /'. This symmetric statement of the validity 
conditions will be seen below to result in a rather simple and pleasant proof of 
correctness. 

With the above validity conditions in mind, we now attempt to identify the various 
events of the LRM interface and the components of the LRM state. We can identify 
immediately several kinds of events that must be in the interface of the LRM. 
Communication with the client requires the existence of a request event request, which 
represents the receipt of a request from the client, and a reply event of the form reply.r, 
in which resource r is allocated to the client in response to a prior request. 
Furthermore, the interface of an LRM must contain events corresponding to the transfer 
of resources between an LRM and its neighbors in the system. Let Resources be the set 
of names of all the resources that the LRM might be called upon to handle. For each r € 
Resources, the LRM interface includes the event parentjn.r, which represents the 
receipt of resource r from an LRM's parent in the tree, and parent_out:r, which 
represents the delivery of resource r by an LRM to its parent. Let Children be a set of 
names used to index the children of the LRM. For each c € Children and r € Resources 
the interface of the LRM includes the event child joufXc, r>, which represents the 
transfer of resource r from the LRM to child c, and the event childjn:<c, r>, which 
represents the receipt of resource r by the LRM from child c. 

To describe the conditions under which transmission of resources between LRM's 
and between a client and an LRM is permitted, we include in the state of each LRM a set 
free, which represents the resources locally available at the LRM, and a nonnegative 
integer pending, which counts the number of unfilled requests that originated at the 
client associated with the LRM. A request event causes pending to be incremented. A 
reply.r event can occur only if pending is nonzero and r € free, and causes pending to 
be decremented and r to be removed from free. The resource transmission events 
parentjn:r and child Jn.r cause r to be added to the set free. The events parent.ouf.r 
and child_out:<c, r> can occur only if r € free, and cause r to be removed from free. 
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We have thus settled the issue of how and when requests and replies are 
transmitted betweeen an LRM and its client, and how resources are shuttled between 
LRM's. However, we have not yet determined how and when an LRM should request 
resources from one of its neighbors, or when an LRM should issue resources to a 
neighboring LRM. To describe the conditions governing the transmission of resources 
between LRM's, we introduce a few more components into the state of an LRM. The 
state of each LRM contains a component pjbalance, and a component cj)alance:c for 
each child c. The component pj>alance represents the instantaneous "balance of 
payments" between the LRM and its parent, and cjzalancex represents a similar 
balance of payments between the LRM and child c. A positive balance represents a 
number of resources owed to the LRM by its neighbor, and a negative balance 
represents a number of resources owed by the LRM to its neighbor. These balances will 
be maintained so that the following relation is invariant: If p is an LRM with child c, then 
the cj>alance.c component of the state of LRM p is always the negative of the 
pj>alance component of the state of LRM c. This reflects the idea that resources owed 
by p to c can be viewed as a debit from the point of view of p, or as a credit from the 
point of view of c. These balances will be updated appropriately as requests are 
forwarded, and as resources travel between LRM's in payment of debts. An LRM will 
transmit resources to its neighbor in an attempt to reduce its indebtedness. 

To represent the forwarding of requests between LRM's we introduce the 
following additional kinds of events into the LRM interface: A forwardjn event 
represents the receipt by the LRM of a forwarded request from its parent. Similarly, a 
forward jouf.c event corresponds to the forwarding of a request by the LRM to child c. 
The event reject jout represents the forwarding of a request by the LRM to its parent, 
and the event reject Jn:c represents the receipt of a forwarded request by the LRM from 
child c. We use the terminology reject for the forwarding of requests upward in the tree 
to emphasize the asymmetry inherent in the parent/child relationship. 

In determining the conditions under which forwarding and rejection events should 
be permitted to occur, we must attempt to avoid the following two bad situations: (1) 
We must avoid the deadlock situation in which two LRM's are stubbornly requesting 
resources from each other, while each of their resource requirements could be fulfilled 
by resources from elsewhere in the system. (2) We must avoid the "livelock" situation 
in which a request is continually shuttled back and forth in the system without ever 
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reaching an LRM with available resources. Our proposal for resolving these difficulties 
is to have each LRM keep estimates of the number of surplus resources available in the 
subtree headed by. each of its children. These estimates are to be optimistic in the 
sense that the estimate held by an LRM for child c is at all times an upper bound on the 
number of surplus resources actually available in the subtree headed by c. Situation (1) 
is avoided by having an LRM request resources from its parent only in the case that it 
has no resources locally available and there are no surplus resources left in any of the 
subtrees headed by its children. Situation (2) is avoided by requiring that an LRM only 
send a request to a child c if it estimates that there is a surplus of resources in the 
subtree headed by c. The effect of these two requirements is to ensure that the 
following invariant holds: If an LRM p owes resources to its child LRM c, then the 
number of resources owed by p to c is a lower bound on the instantaneous amount by 
which pending requests exceed available resources in the subtree headed by c. Thus p 
never owes more resources to c than are actually required by c's subtree. 

The balances of payments between an LRM and each of its neighbors can be 
combined with the number of pending requests and locally avnilahle resources to 
produce a quantity PBalance, which represents the projected net number of resources 
(positive = surplus, negative = deficit) that would be left at the LRM after all debts are 
paid. The quantity PBalance, defined formally below, is Informally the number of free 
resources, plus the net number of resources owed to the LRM by its neighbors, minus 
the number of pending requests. The forwarding and rejection of requests by an LRM 
to its neighbors is done with the goal of "getting in the black; H that is, reducing the 
projected deficit. 

The remaining components we need as part of the LRM state are the following: 
For each child c, the state of an LRM contains a component c_esf/'m(c) which is an 
integer that represents the optimistic estimate made by the LRM, of the projected 
number of resources that would be available in the subtree headed by child c, once all 
debts have been paid. If c is an LRM whose parent is p, then the state of c also contains 
a component pjastim, which is a local copy of the cj9Stim(c) component of the state of 
LRM p. Thus, not only does an LRM keep estimates of the projected number of 
resources remaining in the subtrees headed by each of its children, but it also keeps 
track of what its parent must currently estimate as the projected number of resources 
remaining in the subtree headed by the LRM. We permit pjBStim and c_estim{c) to take 
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on arbitrary integer values, although it can be shown that if an LRM is used only in a 
system of other LRM's in the way we envision, then pjestim and c_esf/m(c) are 
invariantly nonnegative. 

The important points of the preceding discussion of the LRM events and states 
can be summarized as follows: 

(1) The LRM interface contains events corresponding to requests from and 
replies to the client, transferring of resources from/to its neighbors, and forwarding and 
rejection of requests. 

(2) An LRM state contains a set free of locally available resources and a count 
pending of outstanding requests from the client, to ensure that every request receives a 
response and that no resource is allocated more than once. 

(3) An LRM state contains a record of its "balance of payments" with each of 
its neighbors. Transfer of resources and requests between LRM's is performed to 
reduce indebtedness. If p and c are neighboring LRM's, then the balance kept by p for 
c is the negative of the balance kept by c for p. 

(4) An LRM state contains an estimate of the projected net number of 
resources that would remain, once all debts have been paid, in the subtrees headed by 
each of its children. This information is used to control the forwarding and rejection of 
requests. If p is the parent of c, then c maintains a local copy of p's estimate of the 
projected number of resources remaining in the subtree headed by c. 

11.9.3 Local Resource Manager Specification 

From the informal discussion of the preceding section, we can derive a precise 
local resource manager specification. In the informal discussion above, we made no 
distinction between the root LRM and the other LRM's in the system. Although similar in 
many respects, the precise specifications of these two kinds of LRM's will be slightly 
different since a root LRM has no parent. To avoid redundancy, the specifications of 
the two kinds of LRM will be presented simultaneously, with differences pointed out 
along the way. 

The parameters of the LRM are the following: 
Children: a finite set of children 

Resources: a finite set of resources 

IResources: the subset of Resources held initially by the LRM 
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{estim : c € Children} : initial estimates of the number 

of resources in the subtrees headed by 
each of the children. 

The set Children is a set of names used to identify the children of the LRM. The set 
Resources is a set of names for all of the resources that the LRM might have to deal 
with. This set includes the names of all resources initially held by the LRM, as well as all 
resources that might be transmitted to the LRM at some later instant by its neighbors. 
The set IResources is a subset of Resources that represents the set of resources initially 
available at the LRM. For each c € Children, the parameter estim c is a nonnegative 
number which the LRM uses as its initial estimate of the projected number of resources 
remaining in the subtree headed by child c. Since there will be no debts in an initial 
state, correct use of an LRM requires that each estim c equal the actual number of 
resources initially available in the subtree headed by child c. 

The interface of a node LRM is defined as follows: 
Events NLRM = {X} + [CEvent + SEvent] 
, n NLhM = (X) + [CIEvent + SIEvent] 

0ut NRLM m { X j + [cOEvent + SOEvent], 



where 



and 



CEvent = CIEvent + COEvent 
SEvent = SIEvent + SOEvent 

CIEvent = (request) 

COEvent = [reply: Resource] 

SIEvent = [reject-in: Children + 

forward_in + 

parentjn: Resource + 

childjn: [Children X Resource]] 

SOEvent = [reject_out: + 

forward.out: Children + 
parent_out: Resource + 
child_out: [Children X Resource]] 
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The events listed above have the following intuitive meanings: Client events are 
those in which the LRM communicates with the client, whereas system events are those 
in which the LRM communicates with other LRM's. The client events are classified into 
request events, in which a request is received from the client, and reply events, in which 
a resource is sent to the client in response to a prior request. The system events are 
classified into: forwarding events (forward_out, forwardjn), in which a request is 
forwarded from'an LRM to one of its children; rejection events (reject_out, rejectj'n), in 
which a request is rejected from an LRM to its parent; and resource transfer events 
(parent_out, parenUn, child_out, childjn), in which a resource is transferred from an 
LRM to one of its neighbors. The "Jn" and "_out" suffixes denote the direction in 
which resources or requests flow; thus, forwardjoutx is the event in which a request is 
forwarded from an LRM to child c, whereas forwardjn is the event in which a forwarded 
request is received by an LRM from its parent. 

The interface Events* 1 -*** of a root LRM is obtained by omitting the forwardjn, 
parent_out, rejecLout, and parentjn events. 

The state set for both a node and a root LRM is defined as follows: 
States LRM = [free: Set[Resource], 

pending: Nat, 

p_balance: Int. 

c_balance: [Children -» Int], 

p_estim: Int, 

c_estim: [Children -♦ Int]]. 
The set free is the set of resources currently available at the LRM. The number pending 
is a counter that records the number of outstanding requests. The quantity pj>alance 
records the net number of resources that the LRM either is promised by its parent, or 
promises to send to its parent. If p .balance > 0, then the LRM is promised resources by 
its parent; if p_balance < 0, then the LRM promises to send resources to its parent. The 
mapping cjyalance records similar information for each of the children. The mapping 
cjestim records the estimate of the projected number of remaining resources in the 
subtree headed by each child. The quantity pjestim is the LRM's local copy of its 
parent's estimate for the subtree headed by the LRM, as discussed above. 
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The initial state relation for the LRM is defined below. Recall that we view a finite 
multiset over a given universe as a function that assigns a finite multiplicity to each 
element of the universe. Lambda-notation has been used below as a shorthand for 
denoting particular multisets. 

lnit LRM (g) s q = <free: IResources, 

pending: 0, 

p_balance: 0, 
c_balance: (Xc€Children)(0) 

p_estim: |IResources| + 2 c€Children estim c , 

c_estim: (Xc€Children)(estim c )> 

Thus, in the initial state, all resources in IResources are free, no requests are pending, 
no resources are promised by/promised to any of the neighbors, and the estimated 
surplus of resources in the subtree headed by the LRM is the sum of the number of free 
resources initially at the LRM, plus the sum of all the initial estimates for the subtrees 
headed by each of the children of the LRM. 

We can now give the formal definition of the quantity PBalance discussed above. 
PBalance(g) = |q(free)| - g(pending) + g(p_balance) + 

2 c€ChiWren^ C - ba,anCe )t C )- 

As discussed above, given a state q, PBalance(g) represents the net number of 
resources (positive = surplus, negative = deficit) that would be left at the LRM after all 
debts are paid. 

The state-transition relation Trans NLRM for a node LRM is defined as follows: 
An incoming request from a client gets recorded as pending, 
(request) Pre^^fo, e) se = request 

Next request^' r > S f = <j[(q(pending) + 1 )'&&&"& 

A resource res can be sent to the client if there is at least one pending request, and res 
is in the set of free resources. The resource res is removed from the set of free 
resources, and the number of pending requests is decremented. 

(reply) Pre re pty^' e > res ) me = re P^ :res A res € <*( free ) A 

o(pending) > 
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Next rep|y (Q, r, res) = r = q[(q(free)-{res})/free, 

(Q(pending)-I )/pending] 

Receipt of a forwarded request from the parent means that the LRM promises to send 
one more resource to the parent, and consequently, that the LRM estimates a surplus of 
one fewer in its own subtree. 

(forwardjn) Pre forwardJn (q, e) a e = forwardjn 

Next forward_mto' r > = r = Q[(<7(P-balance)-1 )/p_balance, 

(q(p_estim)-1 )/p_estim] 

A request can be forwarded to child c only if the LRM currently is "in the red" and 
estimates a surplus of resources in the subtree headed by child c. As a result of 
forwarding the request, the number of resources promised by child c is incremented, 
and the estimated number of resources in the subtree headed by c must be 
decremented. 

(forward_out) Pre forwardout (q, e, c) = e = forward_out:c a 

PBalance(q) < a q(c_estim)(c) > 
Next forward_outto> f - c ) sfs q[(q(c_balance)(c) + 1)/c_balance(c). 

(g(c_estim)(c)-1 )/c_estim(c)] 

Receipt of a rejected request from child c means that child c promises to send one 
fewer resource (or requires one more resource) than it did before, and thus the quantity 
cj>alance{c) must be decremented. In addition, the fact that a request has been 
rejected by c means that the resources in the subtree headed by c have been 
exhausted, and thus c_estim{c) should be set to zero. 



(rejecUn) Pre rejecUn (q, e, c) se = reject_in:c 

[(q(c_baU 
0/c_estim(c)] 



Next reieclJn (q, r,c) s r = q[(q(c_balance)(c)-1 )/c_balance(c), 



A request can be rejected to the parent only if the LRM is "in the red" and there is no 
projected surplus in any of the subtrees headed by children of the LRM. By rejecting a 
request, the LRM promises one fewer resource to its parent, and hence reduces its 
projected deficit. In addition, pjestim must be zeroed to maintain the invariant equality 
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between p_estim and the corresponding cjestim component of the parent LRM. 

(reject_out) Pre reject ^(q, e) m e = reject_out a PBalance(q) < a 

(Vc€Children)(q(c_estim)(c) < 0) 
iq, r) = r = q[(q(p_balance) + 1 )/p_balance, 0/p_estim] 



Next 



reject_out x 



The various resource transfer events occur when an LRM owes a debt and has an 
available resource. Their effect is to cancel out some of the debt. 



(parenUn) Pre parentJn (q, e, res) = e = parentjn:res 

[(q(free)U{ro 
(q(p_balance)-1 )/p_balance] 



Next parenUn (q, r, res) s r = q[(q(free)U{res))/free, 



(parent_out) Pre pawntJ0ut (q, e, res) 



(child_in) 



NeX Wnt_outto- r, res) 



Pre chi.d.in^' e - C ' reS > 
Next chi.d.in^' f ' C ' reS ) 



(child.out) Pre chjldout (q, e, c, res) 



Next. 



child.out 



(q, r, c, res) 



= e = parent.out:res) a res € q(free) 

a q(p_balance) < 
= r ■ q[(q(freeH' , es})/free, 

(q(p_balance) + 1)/p_balance] 

= e = child_in:<c, res> 

= r = q[(q(free)U{res})/free, 

(q(c_balance)(c)-1 )/c_balance(c)] 

= e = child_out:<c, res> a 

res € q(free) a q(c_balance)(c) < 
= r = q[{q{1reeh{res})/1ree t 

(q(c_balance)(c) + 1)/c_balance(c)] 



The definition of the state-transition relation Trans RLRM for a root LRM is obtained 
by deleting the pairs above for the forwardjn, parentjout, and parent Jn events, and 
replacing the pair for reject jout events by the following pair for X-events: 



(X) 



Pre x (q, e) = e = X a PBalance(q) < a 

(Vc€Children)(q(c_estim)(c) < 0) 
Next x (q, r) sr = q[(q (p.balance) + 1)/p_balance, 0/p_estim] 



The X-transitions permitted by this pair are necessary for the consistency of the root 
LRM specification: if the reject jout pair were simply deleted as were the forwardjn, 
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parent jout, and parent Jn pairs, then there would be no way for a root LRM to change 
the value of pj>alance and the rely-condition Rely_external RLRM defined below would be 
vacuous. 

To complete the specification of the local resource manager, it remains to define 
the validity conditions. As outlined in the informal discussion above, the validity 
conditions for the node and root LRM's can be expressed in rely- /guarantee-condition 
form as follows: 

Va|Jd NLRM s Re |yNLRM _ Guar NLRM 

VaHd RLRM m Re | y RLRM _ G uar RLRM . 

As was done in the informal discussion, it is convenient to factor the rely- and 
guarantee-conditions into what the LRM relies on each of its neighbors and the external 
environment to provide, and what the LRM guarantees in turn to each of its neighbors 
and the external environment. 

The rely- and guarantee-conditions for the node LRM are defined by 
Rft|y NLRM s R«ly_piirent NLHM A (vp€Children)Rely_chi!d LRM (c) 

Guar NLRM _ Guar_client LRM a Quar_parent NLRM a 

(Vc€Children)Guar_chitd LRM (c). 
The rely- and guarantee-conditions for the root LRM are defined by 

Re i y RLRM _ Reiy_external RLRM a (Vc€Children)Rely_child LRM (c) 

Guar RLRM _ Guar_client LRM a (Vc€Children)Guar_child LRM (c). 

A node LRM relies on the eventual payment of debts owed to the LRM by its 
parent. 

Rely_parent NLRM = D(D(Now(p_balance) > 0) -► 

O(3rGResources)(0ccur8 * parent_in:r)) 

Although a root LRM has no parent, the intuitive significance of a positive value for 
pjba/ance in the case of a root LRM is that the total number of requests in the entire tree 
exceeds the total number of available resources. Since we cannot expect a system of 
LRM's to eventually satisfy all requests under such circumstances, a root LRM relies on 
the external environment to ensure that pj>alance is invariantly nonpositive. 

Rely_external RLRM s D(Now(p_balance) < 0) 
Both kinds of LRM rely on each of their children to eventually eliminate debts owed to 
the LRM, either by the transmission of resources, or by the rejection of requests. 
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Rely_child LRM (c) = D(D(Now(c_balance)(c) > 0) -♦ 

O((3r€Resources)(0ccurs = child_in:<c, r>) v 
(Occurs = reject_in:c)» 

A node or root LRM guarantees to its client that pending requests will eventually 
receive a reply. 

Guar_client LRM = D(Now(pending) > -* 

0(3r€Resource)(Occurs = reply:r)) 
A node LRM guarantees eventually to eliminate debts owed to its parent, either by 
actual transmission of resources, or by rejecting requests. 
Guar_parent NLRM = D(D(Now(p_balance) < 0) -*• 

0((3r€Resources)(Occurs = parent_out:r) v 
(Occurs = reject_out))) 
Both kinds of LRM guarantee eventually to pay debts owed to their children. 
Guar_child LRM (c) s D(a(Now(c_balance)(c) < 0) -♦ 

0(3r€Resources)(Occurs = child_out:<c, r>)) 

In devising the validity conditions for the local resource manager module, it was 
necessary to choose between two possible forms in which to state the rely- and 
guarantee-conditions. Since we are often faced with, such choices in practice, it is 
useful to examine the motivation for the particular choice made here. As an example, 
consider the definition of Guar_parent NLRM , which was stated above in the form 

(1) Guar_parent NLRM = D(D(Now(p_balance) < 0) -* 

0((3r€Resources)(Occurs = parent_out:r) v 
(Occurs = reject_out)» 
This guarantee-condition states that either a parentjout or a rejectjout will occur if 
there is the condition pjbalance < holds persistently (i.e. forever after some point). 
We might also have chosen the apparently stronger alternative form 

(2) Guar_parent NLRM ■ D(Now(p_balance) < -» 

0((3r€Resources)(Occurs = parent_out:r) v 
(Occurs = rejecLout))). 
which requires the occurence of a parentjout or rejectjout event in the case that the 
condition pjbalance < occurs at a single instant. In fact, we claim these two 
sentences are equivalent in the context of the LRM specification. More precisely, we 
claim Comp LRM N (1) «-* (2). Clearly (2) implies (1) by temporal reasoning alone. To see 
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that Comp LRM N= -«(2) implies -"(1), suppose Comp LRM and -»(2). Then 

(*) 0(Now(p_balance) < a D((Vr€Resources)(Occurs * parent_out:r) a 

(Occurs * reject_out))). 
That is, eventually there is a point at which pj>alance < holds, but after which no 
parentjout or reject jout events ever occur. Inspection of the state-transition relation for 
the LRM shows that the only events that can cause pj>alance to be increased are 
parentjout and reject jout events. This means that, if no parentjout or reject jout events 
occur, then p_balance < 0, once established, holds forever. Applying this result to (*) 
shows that 
(* *) 0(D(Now(p_balance) < 0) a 

D((Vr€Resources)(Occurs * parent_out:r) a 
(Occurs * reject_out))). 
But (* *) is precisely the negation of (1 ) above, and thus (1 ) and (2) are equivalent. 

In this example, where form (1) and form (2) are equivalent, we chose form (1) over 
form (2) because form (1 ) is more convenient for the proof of correctness. Once we 
have decided en form (1 ) for the guarantee condition Guar_parcnt NLRM , we must use the 
same form for the complementary rely-condition Rely_child LRM (c). Similar arguments 
apply to Guar_child LRM (c) and Rely_parent NLRM . 

11.9.4 The Resource Manager Implementation Algebra 

In this section we define the resource manager implementation algebra A RMI . Let 
the following be given as parameters: 

Clients: a finite set of clients, 

root: a distinguished element of Clients 

Children: Clients -* Set[Clients] maps each client to a set of children 
Resources: a finite set of resources 

{Resources : c € Clients}: the initial partitioning of Resources. 

We require that <Clients, root, Children> be a rooted tree. Let parent: (Clients - {root}) 
-► Clients be the function that maps each c € Clients to its parent. Define the function 
PDesc: Clients -*■ Set[Clients], which takes an element c of Clients to the set of all 
proper descendants of c, in terms of the function Children in the obvious way. Define 
Desc(c) = {c} U PDesc(c) for all c € Clients. 
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The set Clients will be the index set for the interconnection; that is, there will be 
one LRM corresponding to each element of Clients. Define the embedded algebras A abs 
and {A p : p € Clients} as follows: 

^abs : is tne resource manager event/state algebra A™*, with parameters 

Clients, Resources instantiated as Clients, Resources, respectively. 
*root : is tne ,oca ' resource manager event/state algebra A LHM , with 

parameters Resources, IResources, Children, {estim c : c € Children(root)} 
instantiated as Resources, Resources root , Children(root), {2 d€Desc(c) 
|ResourcesJ: c € Children(root)}, respectively. 
A : where p € Clients - {root}, is the local resource manager event/state 

algebra A L * M , with parameters Resources, IResources, Children, {estim c : c 
€ Children(p)} instantiated as Resources, Resources p , Children(p), 
{E deDesc(c) |ResourcesJ: c € Children(p)}, respectively. 

Let the composite interface for the resource manager interconnection be defined 
as follows: 

Events RMI = {\} + [rwqu«st: Clients + 

reply: (Clients X Resources) + 

forward: (Clients - {root}) + 

reject: Clients + 

down: {(Clients - {root}) X Resources) + 

up: ((Clients - {root}) X Resources)] 

(n RMi _ ^j + [ re q Ues t : Clients] 

Out RMI = {X} + (Events^'-ln™ 1 ). 

Intuitively, the event requesf.p corresponds to the receipt of a request by LRM p 
from its client, and reply.<p, r> corresponds to the allocation of resource r by LRM p to 
its client. The event forwardip represents the simultaneous occurrence of a forward Jn 
event for LRM p, and a forwardjoutip event for LRM parent(p). The event reject:p 
represents the simultaneous occurrence of a rejectjout event for LRM p and a 
rejectjnip event for LRM parent(p). The event down:<p, r> represents the simultaneous 
occurrence of a parent Jn:r event for LRM p and a child Lout:<p, r> event for LRM 
parent(p). Finally, the event up:<p, r> represents the simultaneous occurrence of a 
parent jouf.r event for LRM p and a child Jn:<p t r> event for LRM parent(p). Formally, 
these relationships are captured by the following definitions of the abstraction map a RMI , 
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and the decomposition map £ RMl = <5 RMI > 
o RMI (e) = request: c 
= reply:<c, r> 
= A 



p€C1ients' 

if e = request: c 
if e s reply:<c, r> 
otherwise. 



sRMI 



(e) = request 
= reply.r 
= forwardjn 
= forward_out:c 
= reject_out 
= reject_in:c 
as child_in:<c, r> 
= child_out:<c, r> 
= parent_out:r 
= parentjn: r 
= X 



ife = request:p 

if e = reply:<p, r> 

if e = forward:p 

if e = forwards and p = parent(c) 

ife = reject:p 

if e = reject:c and p = parent(c) 

ife * up:<c,r>andp = parent(c) 

if e = down:<c, r> and p = parent(c) 

if e = up:<p, r> 

if e = down:<p, r> 

otherwise. 



11.9.5 Proof of Correctness 

In this section we prove the correctness of the implementation <3^rmi, S ab3 , 

< S c > c€C.lents > ' where S rt» is defined ** <*«»> ^^^ S root is defined b * 

<A noV Valid RLRM >, and S c for c € Clients - {root} Is defined by <A C , Valid NLRM >. 

Implementation Invariant: 

As usual, we factor the implementation invariant lnv RM, (g) for the resource 
manager implementation into an abstraction relation Abs^'to) and a representation 
invariant Rep RMI (q). The abstraction relation simply states that the set of free resources 
for the abstract resource manager module is just the union of the sets of free resources 
for each of the component LRM's, and that the multiset of pending requests for the 
abstract RM assigns to each client a multiplicity equal to the value of the state variable 
pending for the corresponding LRM. 

Abs RMI (o) = Q abs (free) = U c€Client8 q c (f ree) A 

q abs (pending) = (Xc€Clients)(q c (pending)) 
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It is convenient to factor the representation invariant into several conjuncts: 
Rep RMI (g) s Disjoint(g) a Neighbor(g) a Owed(g) a Optim(g). 

The conjunct Disjoint(g) states that the sets of free resources possessed by two distinct 
LRM's are disjoint. 

Disjoint(g) a A c c €ciients (c * c ' - g c (free) n g c .(free) = 0). 

The conjunct Neighbor(g) expresses the consistency constraints that hold between the 
values of the state variables for neighboring LRM's. 

Neighbor(g) ee A p€CUent8c€Children(p) {(g c (p_balance) = -o p (c_balance)(c)) a 

(g c (p_estim) = g p (c_estim)(c))} 

The conjunct Owed(g) states that an LRM can be owed resources by its parent only if 
the LRM estimates no surplus in the subtree of which it is the root. 
Owed(g) = A p€CHents (g p (p_balance)>0- 

PBa!ance(g p ) + 2 cCChi)dren(p) g p (c_estim)(c) < 0) 

The conjunct Optim(g) states that the estimate pjestim held by an LRM p is optimistic in 
the sense that it is an upper bound on the actual projected number of resources 
remaining in the subtree of which p is the root, assuming that each estimate c_estim{c) 
held by p is an upper bound for the subtree rooted at c. 
Optim(g) s A p€Clients (Q p (p_estim) £ 

PBalance(g p ) ♦ 2 cecwidren(p) Q p (c_estim)(c)). 

To show the inductiveness of lnv RMI (g), first note that the basis step, i.e. that 
lnit RM, (g) -* lnv RM1 (g) holds for all g € States, is easily checked. A complete formal proof 
of the induction step, namely, that Trans RM, (g, e, r) -♦ (lnv RMI (g) - lnv RMI (r)), would be 
performed by case analysis on the event e. Such a complete proof would be quite 
tedious to read, and will not be included here. Rather, we will remark on the cases that 
are not quite trivial. Assume that Trans RMI (g, e, r) and lnv RMI (g) holds, to show lnv RMI (r)- 
We consider each of the conjuncts of lnv RM, (r) in turn. 

Abs RMI (r): The truth of this predicate depends upon the values of r e (free) and 
r c (pending), for each c € Clients, as well as ^(free) and r abs (pending). The events e 
that affect the pending components of the state are requestx and reply.c. The effect of 
requestx is to add one instance of c to the multiset g abs (pending), and to increment the 
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value of Q c (pending) by one. Clearly this preserves the desired invariant relationship. 
The case of e = reply:<c, res>, is similar. The events e that affect the free components 
of the state are up:<c, res>, down-Ac, res>, and replyx. Because of the fact that each 
upAc, res> or down:<c, res> is participated in only by LRM c and its parent, and the 
effect on the states of these two modules is complementary, it is easily verified that 

u c€c«ents r c ( free ) = U c€ciients <M fre€ )' no,ds for e = down:<c, res> or upAc, res>. The 
case e = reply-Ac, res> is slightly more troublesome, since to show that U c€clients r c (free) 
= ( U c€CHents 9 c (free)) " ( fes 3' we need to make use of the inductive assumption that 
Disjoint(q) holds. From this we know that if res € q c (free), for some c € Clients, then res 
€ q c (free) for all c ' * c, and hence deleting res from q c (f ree) in fact deletes it from the 
union of the free sets for all the component modules. 

Disjoint(r): The truth of this predicate depends only upon the values of rffree) for each 
c € Clients. These components of the state are affected only by events of the form 
replyAc, res>, upAc, res>, and down Ac, res>. In case e * replyAc, res>, we have that 
r c (free) = g c (free) - {res} and r. .(free) = q c .(free) for all c ' € Clients with c ' *■ c. In 
case e = upAc, tes>, and c € Childien(p), we have that r (free) = q (free) U {res}, 
r c (free) = q c (free) - {res}, and r c -(free) = q c .(free) for all c ' G Clients with c ' G Clients - 
{c, p}. In case e = dowm<c, res>, and c € Children(p), we have that r (free) = q (free) 
- {res}, r c (free) = g c (free) + {res}, and r c .(free) = q c .(free) for all c ' € Clients with c ' € 
Clients - {c, p}. In each of these cases it is easily checked that Disjoint(r) holds. 

Neighbor(r): Note that the predicate Neighbor(r) depends upon the values of 
r c (p_balance), r c (c_balance), r c (p_estim), and r c (c_estim), for each c G Clients. 
Enumeration of cases shows that the only events that affect the values of these 
components of the state are the events rejectx, forwardx, downXc, res>, and 
up:<c, res>. However, examination of the definition of the LRM state-transition relation 
and the definition of the decomposition map 1 ^ shows that each change in the state 
of a participant in one of these events is accompanied by a compensating change in the 
state of the other participant. For example, if c € Children(p), then occurrence of an 
event of the form rejectx makes r c (p_balance) = q c (p_balance) + 1, but also makes 
r p (c_balance)(c) = q p (c_balance)(c) - 1 . Thus the predicate Neighbor is preserved. 

Owed(r): Assuming that Owed(q) holds, the only way for Owed(r) to be false is for an 
event e to occur that increments q (p_balance) when it is zero, or increments 



174- 



PBalance(g ) + 2 cCChjldren(p) g p (c_estim)(c) when it is zero. The only events that might 
have this property are e = reject.p, and up:<p, res>. In case e = reject:p, PBalance(g p ) 
+ 2 c€Chiidren(p) QpCc-^t'roHc) is incremented, but the precondition for this event 
requires that this quantity be less than zero, so Owed(r) holds. In case e = up:<p, res>, 
the quantity g (p_balance) is incremented, but the precondition for e requires that this 
quantity be strictly negative, and hence Owed(/-) holds. 

Optim(r): Assuming that Optim(g) holds, the only way for Optim(r) to be false is for the 
quantity g c (p_estim) to be decreased below the quantity PBalance(g c ) + 2 d€Chjldren(c) 
g c (c_estim)(d), or for the latter quantity to be increased above the former. The only 
events that could possibly have this effect are forwardx and rejecV.c. If e = forwardx, 
then g c (p_estim) is decremented, but so is PBalance(g c ) + 2 <y€Chj(dren(c) g c (c_estim)(cQ. 
If e = rejectx, then PBalance(g c ) + 2 d€Children . c) g c (c_estim)(d) is incremented and 
g„(p_estim) is set to zero. However, the precondition for e requires that the former 
quantity be negative. This fact implies that PBalance(r c ) + 2 d€Chi|dren(c) r c (c_estim)(d) < 
and r c (p_estim) = 0, and Optim(r) holds. 

From the invariance of Owed, Neighbor, and Optim, we can derive the 
fundamental property of estimates upon which the correctness of the resource 
management system crucially depends. This property Is expressed by Lemma 11.1 
below, which states that if an LRM / is owed resources by its parent, then the amount it 
is owed by its parent is a lower bound on the total instantaneous deficit in the subtree of 
which / is the root. To express this result formally, we introduce the quantity IBalance(q) 
where g is an LRM state, defined as follows: 

IBalance(g) = |g(free)|-g(pending). 
Whereas the quantity PBalance(q) introduced previously represents the total projected 
balance of resources at an LRM, after all debts have been paid, the quantity IBalance(q) 
represents the total instantaneous balance of resources at an LRM, where the amount 
of indebtedness is not taken into account. 

Lemma 11.1 - The following is invariant for the resource manager implementation: 

g p (p_balance) < -2 c€Desc(p) IBalance(g c )) 

Proof - From their definitions, it is easily seen that the quantities PBalance(q) and 
IBalance(q) are related by the following identity, expressed in the language 1(A LRM ) of 
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the LRM event/state algebra: 

PBalance(g) = IBalance(g) + g(p_balance) + 2 c€Children q(c_balance)(c). 
From this identity, a simple induction on the height of a node /' € Clients in the tree 
<Clients, root, Children>, shows the truth of the following identity for all / € Clients: 
< 1 > 2 /€Desc(/) PBalancefy.) = g^p.balance) + 2 /€Desc(p) IBalancefop. 

That is, the total projected balance in the subtree of which / is the root is equal to the 
total instantaneous balance in that subtree, plus the net number of resources promised 
to be exchanged with the parent of /. 

The invariance of Owed(g) means that the following is invariant: 

< 2 > A /€Clientsfa/<P- ba,anCe > > ° "* 

PBalancefy) + 2, €CMdmnW g,(c_estim)(/) £ 0). 

That is, if an LRM / is owed resources by its parent, then it must estimate no surplus of 
resources in the subtree of which / is the head, based on the estimates it has for each of 
iis children. 

The invariance of Neighbor(g) implies that the following is invariant: 
@> A, €Clten JV7€Children(/))(g / (c_estim)(/) = g/p.estim)). 

Substitution of (3) into (2) shows the invariance of 

PBalance(g,) + 2 y€Children(0 Q/p.estim) < 0). 
Using the invariant Optim(g) to substitute for q^p.estim) in (4) shows that 

< 5 > ^ectenxstoito-tetence) > - 

PBalancefa,) + Z yecwidren(0 (PBalancety) + 

is invariant. Repeating this argument to eliminate all occurrences of c_estim yields the 
invariance of 

< 6 > A /cc.ient s fa,(P- balance > > ° "* 2 /€Desc(o PBalancety < 0), 
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which states, intuitively, that if LRM / is owed resources by its parent, then there can be 
no projected surplus of resources in the subtree of which /' is the root. 

By using (1) to eliminate PBalance in favor of IBalance in (6), we obtain the 
invariance of 

( 7 > A /ec« i entsto/<P- balance > > ° - 

o\(p_balance) + 2 y€Dete(0 IBalancety.) £ 0), 

which is equivalent to the desired result. I 

Proof of Maximality 

The maximality verification condition is: 

N (Vc/€States, e€Events){lnv RM, (g) a A c€aients Enabled c (q, e) 

— Enabled abs (g, e». 
The proof of this assertion is most easily performed by a case analysis on the event e; 
making use of the fact that the module specifications define the state-transition relation 
by precondition /next-state predicate pairs. If e = forwardx, rejecf.c, down:<c, r>, or 
up:<e, r>, then a PM, (e) = A, and hence Enauled abs (g, e) s true. We therefore need 
consider only the cases e = requesf.c and e = reply:<c t r>. If e = requesV.c, then 
o RMI (e) = requesf.c, and hence Enabled ab8 (g, e) s true. 

We are left with the case e = reply:<c, r>. In this case, we obtain the following 
from the module specifications: 

Enabled abs (q, e) s r € o abs (free) a c € appending) 
Enabledfq, e) = r € gjfree) a gfpending) > 

c c c 

Enabled p (g, e) m true, if p € Clients - {c}. 

Assume lnv RMI (g), and hence Abs RM '(g), holds. Assume further that A peciients 
Enabled p (o, e) holds. From Enabled c (g, e) we know that r € g c (free) a appending) > 
holds. From this and Abs RMI (g) we infer that r € Q abs (tree) a c € Q abs (pending) holds, as 
desired. 

Proof of Validity 

To prove that the validity verification condition holds for the resource manager 
implementation, we use Corollary I.5. To apply Corollary I.5, we must find, for each /, /, € 
Clients + {abs}, a sentence RG. , of 9(A RMI ) such that the following hold: 
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(RMI1)(a) Comp RMI N= SRely™!^ - A /€Client8 RG^. 

(RMI1)(b) Comp™ N A /€Client8 RG, abs - JGuar"^^ 

(RMI2)(a) 

(root) Comp RM1 N (A, €clients+{abs} RG, f00l - BRely RLRM ]| root > 

(node) Comp™ N A /£cltente _ {rool) (A /€CIienls+{abs} RG,,. - HRely NLR *%) 

(RMI2)(b) 

(root) Comp RMl 1= (IGuar RLRM ]| root - A /€clients + {abs} RG rooW ) 

(node) Comp^' t= A /€c|tenMroot} (IGuar*"-™!,. - A /€C(ients+{abs} RG,,) 

(RMI3) Whenever {<J Q , /,>, </,, /' 2 > </„_i- '«>) is a ^ cie of c,ients ' then 

Comp^NVj^RG^^. 

The sentences RG^. bear a particular relationship, formalized in Lemma II.2 below, 
to the various conjuncts appearing in the local resource manager validity conditions. 
Lemma II.2 states in essence, that the local resource manager validity conditions are 
"localized" versions of the sentences RG„. Part (a) of Lemma II.2 states that the 
sentence RG .„ captures exactly what LRM / guarantees to its parent and exactly 
what LRM parent(/) relies on / to provide. Part (b) states that the sentence RGparentwj 
captures exactly what LRM / relies on its parent to provide, and exactly what LRM 
parent(/) guarantees to provide to /. Part (c) states that the sentence RG abs root captures 
exactly what the root LRM relies on the external environment of the system of LRM's to 
provide. Part (d) states that the sentence RG, ab8 captures exactly what LRM i 
guarantees to provide to the external environment of the system of LRM's. 

The sentences RG,, are defined as follows: 
RG Wabs s D(Now root (pending) > - 

O(3r€Resources)(«;j2|(0ccurs) = reply:r)) 
RG Woot s a<Now root (p_balance) < 0) 
For all /', / € Clients - {root}: 

RG,. abs s D(Now,(pending) > -*• 

OpreResourcesMSj^Occurs) = reply:r)) 

RG W = true - 

For all i € Clients - {root}: 

RG ,.parent(o s □(n<Now,.(p_balance) < 0) - 

0((3/-€Resources)(fi ( RMI (Occurs) = parent_out:r) v 
(5 RM, (Occurs) = rejecLout)) 
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RG parent(,v s n(D(Now piMnlw (cJ)alance)W < 0) - 

OprCResourcesM^J^Occurs) = child_out:</', /•>)) 

For all /,/€ Clients such that neither / = parent(/)or7 = parent(/): 



RG /V = true. 

Lemma II. 2 - The following are valid for the resource manager implementation: 

(a) For all / € Clients - {root}, 

Comp™ •= RG /.parent(i) " 

[Guar_parent NLRM l / ♦+ 
5Rely_child LRM (01 parent{0 

(b) For all / € Clients - {root}, 

Comp RMI N RG parenl{/) . ~ 

|Rely_parent NLRM l y «-♦ 

IGuar_child LRM (/-)ll parent(/) 

(c) Comp RMI K= RG abs root ~ JRely_external RLRM l root 

(d) For all /€ Clients, 

Comp™ N RG /abs ~ iGuar_client LW< S r 

Proof - Straightforward, using the invariance of Neighbor and the definition of the 
decomposition map Sl rmi - ■ 

Lemma 11.3 - Under the definitions given above for the sentences RG lV , conditions 
(RMI1)-(RMI3) hold for the resource manager implementation. 

Proof - Assume Comp*™ 1 . 

To prove that (RMI1 )(a) holds, we must show 

IRely^l^-A^^RG^, 
Suppose that iRely^J,^ holds. It suffices to prove that RG ab8 root holds, since RG abs , s 
true for all / € Clients - {root}. |Rely RM J abs is defined by: 

JRely™!^ m D(|Now abs (free)| > |Now ab8 (pending)|). Using this and the 
invariance of the predicate Abs RMI , we infer the truth of D(2 /eaients (|Now,(free)| - 
Now^pending)) > 0), which is equivalent to 



(A) □(Z, €ajents IBalance(Now / ) > 0). 
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From Lemma 11.1 and the fact that Desc(root) = Clients, we infer that 
D(Now rool (p_balance) > - Now root (p_balance) < -2 /€Ctents IBalance(Now.)). From 
this and (A), we conclude that D(Now root (p_balance) <. 0), which is precisely the 
statement that RG abs root holds. 

To prove (RMI1)(b), we must show 



'Vciients RG /,abs " U« u «' il a bs 

Suppose that A, ecijents RG, abs holds. From the definition of RG ; . ab8 we know that 

A. £Clients D(Now.(pending) >0- OpreResourcesKSf^Occurs) = reply:/-)) 
holds. From the invariance of Abs RMI and the definition of the abstraction map o RMI we 
infer that 

A /€c.ien«s D <'' € Now abs (pending) - 

0(3r€Resources)(o RMI (Occurs) ■ reply:</,r>)) 

holds.- This is precisely the statement that fiGuar RM I abs holds. 

We next prove (RMI2)(a). In case {root), we must show 
(root) A, €cltents+{abs} RG, roo , - BRely RLRM l roor 
From the root LRM specifications we know that 

SRely_external R1 - RM ! root a A ;€Children(root) ttRely-Child LRM (01 root - IRely RLRM J root . 
Using Lemma II. 2 (a) and (c) we infer that 

RG abs,oot A A /€Chi W ren(root) RG / 1 roo» - IRa^X* 

which implies formula (roof). 

In case (node) we must show that for all /' € Clients, 

(node) A ;£cltents+{abs} RG,, - BRely NLRM l r 

Fix } to be an arbitrary element of Clients. From the node LRM specifications we know 

that 

IRely.parent^^ a A /echildrenW IRely.child LRM (/-)l y - BRely^™!,. 

Using Lemma II. 2 (a) and (b) we infer that 

which implies formula (node). 

We next show (RMI2)(b). In case (root) we must show 
(root) IGuar 1 *™!,^ - A /€CHents+{abs} RQ rooXJ . 
From the root LRM specifications we have 

iGuar^JU - SGuar_client LRM l root a A /CChjtdren(root) IGuar_child LRM 0)l root 
Using Lemma 11.2 (b) and (d), we infer 
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|Guar RLRM ]| root «-* RG rootabs a A /€Children(rool) RG rootJ . 
This implies formula (root), since RG rooU m true unless/ = abs or/ € Children(root). 
In case (node) we must show that, for all / € /: 
(node) |[Guar NLRM ] ; - A /€c|ients+{llbs} RG„. 

Let / be an arbitrary element of Clients, and assume ffGuar* 41 -^. From the node LRM 
specifications we have 

|Guar NLRM ]]. «-* JGuar_client LRM ]l / a aQuar-parent" 1 -™!, a 

A y€ Chi.dren(0lI Guar - Chi,dLRM Wl/ 

Using Lemma 11.2 (a), (b), and (d), we infer 

IGuar^B, - RG, abs a RG. (Parentw a (V/€Children</))RG /(r 
This implies formula (node), since RG^ a true unless / * abs, / = parent(/), or / € 
Children{/). 

To prove (RMI3) it suffices to show that RG,^^ v RG parent(/)/ . holds for all / € 
Clients - {root}. This is because every cycle {</ , /,>, ... , </„_.,, /„>} of Clients either 
contains a link </\, /; ,> for which RG, , m true by definition, or else contains both 
links </', parent(/)> and <parent(/), O for some / C Clients - {root}. 

To show RG, parent(/) v RG parent(0>/ holds for all / € Clients - {root}, let / be arbitrarily 
fixed, and suppose that "»RG, parcntw holds, to show that RG^^ holds. By definition 
of RG, .,* we know that OD(Now,(P-balance) < 0) holds. By the invariance of 
Neighbor, we infer that ODtNow^^cJaalanceKO > 0) holds. This implies that 

RGpa re nt(o, ho,ds - ■ 

11.10 A Message Transmission System 

In this section we consider the specification and implementation of a message 
transmission module TM, whose function is to reliably deliver messages input by one 
user, called the sender, to another user, called the receiver. Messages should be 
delivered in the order in which they are sent, and should not be subject to loss or 
duplication. The message transmission module therefore behaves as a FIFO buffer 
between the sender and the receiver. The interesting part of this example is how the 
reliable FIFO buffer behavior of the message transmission module is implemented by a 
transmission module implementation TMI, which consists, in part, of unreliable 
transmission line components. This is accomplished through the use of a send protocol 
module and a receive protocol module, which together implement the alternating bit 
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protocol [Bartlett69]. 

The alternating bit protocol is a standard example for which correctness proofs in 
varying styles have been given by other researchers. Most analyses treat only safety 
properties, however the proofs given by Hailpern and Owicki [Hailpem80] and Lamport 
[Lamport83] treat fiveness properties of the protocol in addition to safety properties. 
The major deficiency of Hailpern and Owicki's treatment is the unstructured and 
apparently ad hoc nature of the specifications and the correctness proof. It is difficult to 
discern from their work very much in the way of a general method (with the exception of 
their use of history variables, which can be seen as a special case of the state-transition 
approach espoused here) likely to be applicable to other examples. In contrast, the 
specifications and correctness proof given below are an instance of a general strategy, 
which is embodied in the state-transition approach to specification, the use of rely- and 
guarantee-conditions, and the Correctness Theorem. 

Of the extant proofs of the correctness of the alternating bit protocol, that of 
Lamport [Lamport83] is perhaps the most similar to the one given here. The modules 
are specified in a state-transition style quite like that proposed here. It is possible to 
identify portions of Lamport's proof that correspond to the proof of invariance of the 
abstraction relation and implementation invariant given below. The major difference 
between Lamport's proof and the one given here is in the statement and proof of the 
liveness (i.e. validity) properties. Lamport's liveness specifications for the send protocol 
module take the form: "If the send protocol module has an unprocessed message, then 
it will eventually give a packet containing that message to the unreliable transmission 
medium for transmission to the receive protocol module;" "If a correct 
acknowledgement is received by the send protocol module, then eventually the protocol 
will progress to the next unprocessed message;" etc. These are "low-level" 
specifications that can be thought of as essentially a set of assertions that might appear 
in an assertional proof that a particular program satisfies the specification. In contrast, 
the specifications given here are of the form: "If the send protocol module can rely on 
the fact that sufficiently many transmissions of packet p will eventually result in the 
receipt of an acknowledgement for packet p, then it guarantees eventually to process 
every message given to it as input." This Is a "higher-level" specification that states 
what the send protocol module accomplishes without detailing a chain of intermediate 
steps by which it is accomplished. 
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A feature that distinguishes the proof presented here from previous proofs, is that 
the proof here is to a great extent independent of the precise assumptions on the 
reliability of the transmission line components. The specifications of the transmission 
line module are expressed in the form: "If a message m is transmitted according to 
certain conditions Xmit(m), then eventually m will be delivered according to conditions 
Dlvr{m)." For concreteness, we use "m is transmitted repeatedly, without intervening 
transmission of any different message m '" for Xmit(m), and a symmetric condition for 
Dlvr(m). However, Xmit(m) and Dlvr(m) can easily be replaced with alternative 
conditions without change to the proof structure. 

11.10.1 Specification of the Message Transmission Module 

The interface of the message transmission module TM consists of two kinds of 
events: those of the form TMJn:m, in which message m is presented to the transmission 
module by the sender, and events of the form TMjout.m, in which message m is 
delivered by the transmission module to the receiver. We wish to state that the 
transmission module delivers messages in FIFO order without loss or duplication. We 
can think of the state of the transmission module as a sequence of the messages input 
by the sender but not yet delivered to the receiver. Equivalents, and for our purposes 
more conveniently, the state of the transmission module can be thought of as a pair 
<inq, outq> of sequences of messages, where inq represents the entire history of 
messages that have ever been input to the transmission module by the sender, and outq 
represents the entire history of messages that have ever been output to the receiver by 
the transmission module. The sequence of messages sent but not yet delivered by the 
transmission module is represented, in this alternative state set, by the sequence 
inq-outq. 

Based on this selection of state set, let us now derive a precise specification of the 
transmission module. 

Let Values be a finite set of message values, given as a parameter. The interface of the 
transmission module is defined as follows: 

Events™ = {A} + [TM_in: Values + TM_out: Values]. 

In™ = {X} + [TM_in: Values] 

Out™ = {X} + [TM_out: Values]. 
The state set for the transmission module is defined by: 
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States™ = [inq: Seq[Values] X outq: Seq[Values]]. 
If q € States™, then we write q(inq-outq) as an abbreviation for q(inq) - q(outq). 

In an initial state for the transmission module, the queue is empty. 
Init™(q) = q(inq) = q(outq). 

The state transition relation Trans™ is defined by precondition/next-state 
predicate pairs as follows: 

An input event with message m can occur at any time, and causes message m to be 

appended to the end of inq. 

(TMjn) Pre TMJn (q, e, m) = e = TM_in:m 

Next TMJn (q, r, m) m r = q[(q(inq))-m/inq] 

An output event with message m can occur only if there is a message that has been sent 
but not yet delivered, and m is the first such message. The effect is to append m to the 
end of outq. 

<TM_out) Prc TM out (q, c.m) s e = TM_out:m a g(outq) < g(lnq) a 

m = (q(inq-outq)(0) 
Next TM out (q, r,m) s r = q[(q(outq))»m/outq]. 

We wish the validity condition for the transmission module to capture the 
requirement that every message sent is eventually delivered. This is captured by the 
definition below, which states that, given any prefix s of inq, there is eventually a later 
time at which s is also a prefix of outq. 

Valid™ s Rely™ -* Guar™ 
where 

Rely™ s true 

Guar™ s D(VseSeq[Values])(s < Now(inq) - 0(s £ Now(outq))). 

11.10.2 Implementation of the Transmission Module 

Figure 4 shows the implementation of the transmission module by a send protocol 
module SP, a receive protocol module RP, a sender-to-receiver transmission line 
module SRTL, and a receiver-to-sender transmission line module RSTL. Messages 
received from the sender by the send protocol module (an "in" event) are placed in a 
queue for transmission to the receive protocol module. When this queue is nonempty, a 
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packet consisting of the first message in the queue and a current boolean sequence 
number is transmitted (via a "pkt_out" event) by the send protocol module SP over the 
transmission line SRTL. In contrast to the reliable transmission module specified in the 
preceding section, the transmission line module is inherently unreliable, and might lose 
or duplicate messages. We require, however, that the transmission line not reorder 
messages. Since messages might be lost, in general it will be necessary for the send 
protocol module to transmit the same packet a number of times before it is delivered to 
the receive protocol module. Thus the send protocol module continues to send the 
packet until an acknowledgement for the sequence number it contains is received (an 
"ack_in" event) over the transmission line module RSTL. Receipt of a correct 
acknowledgement by the send protocol module causes the first message to be removed 
from its queue. In addition the send protocol module complements its sequence 
number. 

When a packet arrives at the receive protocol module (via a "pkt_in" event), it is 
checked to see if its sequence number is current. If the sequence number is current, 
then the message is extracted and niareri in a queue of messages to be delivered to the 
receiver. Also, the sequence number expected by the receive protocol module is 
complemented. The receive protocol module ignores packets that do not contain the 
current sequence number. The receive protocol module transmits acknowledgements 
for the most recently received packet over the transmission line module RSTL (via 
"ack_out" events). Whenever the queue of messages to be delivered to the receiver is 
nonempty, then a message can be removed and sent to the receiver (via "out" events). 

11.10.3 Specification of the Transmission Line Module 

The interface of the transmisssion line module contains events of the form 
TLJn:m, which correspond to the presentation of message m for transmission, and of 
the form TLjouf.m, which correspond to the delivery of message m to its destination. 
Thus, the interface of the transmission line module TL is isomorphic to that of the 
message transmission module. The difference between the two modules lies in the fact 
that, whereas the transmission module guarantees to deliver each message exactly 
once, the transmission line module is permitted to lose or duplicate messages any 
number of times. We require, however, that the transmission line module not reorder 
messages. Also, we require that repeated input of messages to the transmission line 
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Fig. 4. Transmission Module Implementation 
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module will eventually cause messages to be delivered. 

We will use the same state set for the transmission line specification as we used for 
the transmission module specification. However, the intuitive meanings of the 
components inq and outq of the state are significantly changed, as is the state-transition 
relation and validity condition. For the transmission line module, the sequence inq 
represents a sequence of messages, each of which is destined to be delivered at least 
once. However, each message in inq might be delivered more than once. The 
sequence outq represents the messages in inq, each of which has already had all its 
copies delivered, and will therefore never be delivered again. The state transition 
relation is modified to permit message loss and duplication as follows: The possibility of 
message loss is captured by the fact that input events are permitted either to produce 
no state change (corresponding to the loss of the associated message) or to append the 
message exactly once to the end of inq (indicating that the message is destined to be 
delivered eventually at least once). The possibility of message duplication is captured 
by the fact that output events are permitted either to produce no state change 
(corresponding to the duplication of the message iust delivered) or to add the message 
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to outq (corresponding to the delivery of the final copy of the message). 

Note that the preceding description is only one of many possible ways of 
presenting the same transmission line specification. For example, we could have 
captured the possibility of message loss or duplication by stating that the occurrence of 
a TLJn.m event causes the message m to be appended k times to inq, where k is a 
nondeterministically chosen natural number. Occurrence of a TL_out:m event would 
then be possible only if m is the first element of inq not also in outq, and would cause m 
to be appended precisely once to outq. The transmission line specification is an 
example of an indeterminate specification (see Section 6.2), which means that a single 
observation can be produced in more than one computation. Although we could give a 
determinate transmission line specification equivalent to the indeterminate version used 
here, the use of an indeterminate specification seems more natural. 

. We now make the above informal specification more precise. As in the case of the 
transmission module specification, let Values be a finite set of message values, given as 
a parameter. Define the interface of the transmission line module as follows: 

Events' 1 - = {X} + [TL_in: Values + TL_out: Values]. 

ln TL = {X} + [TUn: Values] 

Out*"- = {X} + [TL_out: Values] , 

Define the state set of the transmission line module by: 

States""- = [inq: Seq[ValuesJ X outq: Seq[Values]]. 

In an initial state, the transmission line queue is empty. 
lnit TL (g) s q(inq) = q(outq). 
The state-transition relation Trans TL is defined as follows: 

An input event with message m can occur at any time, and either causes no change in 
state (the message is lost) or appends the message to the end of the queue (the 
message is destined to be delivered). 
(TL_in) Pre TLJn (q, e, m) s e » TL_in:m 

Next TLJn (q, r,m) sr = qvr = q[(q(inq))*m/inq] 

An output event with message m can occur only if there is a message that has been sent 
but for which the last copy has not yet been delivered, and m is the first such message. 
The message m is either appended to outq (corresponding to the last copy of m being 
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delivered), or there is no state change (corresponding to the duplication of m). 

(TL_out) Pre TL_outto- e ' m) - e = TL - out:/77 A <*(° utc l> < 9(' n q) A 

m = (q(inq-outq))(0) 

Next TL ^(q, r,m) = f = QVf = q[(q(outq))*m/outq]. 

The validity condition for the transmission line module should express the 
requirement that, for each message m, if the transmission of m satisfies certain minimal 
conditions (e.g. that m is transmitted repeatedly, without intervening transmission of 
other messages), then the transmission line module will ensure that m will eventually be 
delivered according to certain conditions (e.g. m will eventually be delivered repeatedly, 
without intervening transmission of other messages). Formally, 

Valid TL se Rely 11 - -+ Guar TL 

Rely""- m true 

Guar TL m □(VmeValues)(Xmit T V) — ODIvr^m)), 

where Xmit TL (m) describes the conditions required on the transmission of message m 
and Dlvr^/r)) describes the corresponding conditions according to which m will be 
delivered. Aside from the reniiirfimfint that the resulting specification be consistent, 
there is a reasonable amount of flexibility in the choice of the conditions Xmit TL (m) and 
Dlvr^m). We will see later that the particular choice of conditions does not 
significantly affect the proof of correctness of the transmission module implementation, 
as long as the conditions Xmit TL (m) and Dlvr^m) interact properly with corresponding 
conditions appearing in the specifications for the send and receive protocol modules. 
For concreteness though, we make the following definitions: 

Xmit TL (m) s DO(Occurs = TL_in:m) a 

□(Vm '€Values)(Occurs - TLJnim ' -* m ' - m). 

Dlvr TL (m) = DO(Occurs = TL_out:m) A 

□(Vm '€Values)(Occurs = TL_out:m ' -♦ m ' = m). 
Intuitively, the condition Xmit TL (m) states that the message m is transmitted repeatedly, 
without any transmission of other messages m '. The condition Dlvr^m) states that the 
message m is delivered repeatedly, without any delivery of other messages m '. 
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11.10.4 Specification of the Send Protocol Module 

The send protocol module SP interfaces between the sender and the SRTL and 
RSTL transmission line modules. Its function is to implement one half of the alternating 
bit transmission protocol. The interface of the send protocol module consists of three 
kinds of events: SPJn:m, which represents the receipt of message m from the sender, 
SP_p/cf_ouf:p, which represents the transmission of packet p over the unreliable 
transmission line SRTL, and SPjackJmb, which represents the receipt of an 
acknowledgement for sequence number b from the unreliable transmission line RSTL. 

The state of the send protocol consists of three components: a sequence inq of all 
messages that have ever been received from the sender, a sequence outq of all 
messages that have been acknowledged by the receive protocol module, and a boolean 
component sn, which records the current sequence number. Choosing outq to be the 
sequence of acknowledged messages, rather than the sequence of all messages 
transmitted to the SRTL transmission line, allows us to obtain a simpler correctness 
proof than that presented by Hailpern and Owicki [Hailpern80]. In that paper, the use of 
the actual history of messages transmitted requires the correctness proof to define and 
reason about certain functions whose purpose is essentially to extract the history of 
acknowledged messages from the history of all transmitted messages. 

Informally, the send protocol module behaves as follows: Occurrence of a 
SPJn:m event causes the message m to be appended to inq. When there is a message 
to be sent, and processing of all previous messages has been completed, the message 
is paired with the current sequence number to form a packet p, which is then given to 
the unreliable transmission line SRTL to be transmitted to the receive protocol module. 
The send protocol module continues to transmit the packet p until an acknowledgement 
for its current sequence number arrives over the unreliable transmission line RSTL. 
When a correct acknowledgement arrives, the message acknowledged is appended to 
outq, signifying that it has been successfully delivered, and the current sequence 
number is complemented. 

More precisely, let Values be a finite set of message values, given as a parameter. 
The interface of the send protocol module is defined as follows: 

Events** = {X} + [SPjn: Values + SP_pkt_out: Pkts ♦ SP_ack_in: Bool] 
In^ = {X} + [SPjn: Values + SPjackjn: Bool] 



-189 



Out^ = {X) + [SP_pkt_out: Pkts] 

Pkts = [msg: Values X sn: Bool], 

where Pkts is the set of packets. The state set for the send protocol module is defined 
by: 

States SP = [inq: Seq[Values] X outq: Seq[Values] X sn: Bool]. 

In an initial state, the queue is empty, and the sequence number is false. 
Init sp (q) = qr(inq) = q(outq) a g(sn) = false. 

The state-transition relation Trans sp is defined as follows: 

An SPJn:m event can occur at any time, and causes the message m to be appended to 

inq. 

(SPJn) Pregp jn (q, e,m) = e = SPJn:m 

Next spjnfa- r « m ) s r = <?[(Q( in Q))' m/inc >] 

An SP_pktjout:p event can occur only if there is a message that has been received from 
the sender but not yet successfully transmitted to the receiver, p(msg) is the first such 
message, and p(sn) is the current sequence number. There is no effect on the state. 
(SP_pkt_out) Pr e S p_pkt_outfa' e > P> - e = SP_pkt_out:p a q(outq) < q(inq) A 

p(msg) = (q(inq-outq))(0) a p(sn) = q{sn). 

Next s P _ P M_outto.''.P) = ' = <*• 

An SP_ack_in event for acknowledgment b can occur at any time. If b does not match 
the current sequence number, or if there is no message currently being transmitted, 
then there is no change in state. If b does match the current sequence number and 
there is a message currently being transmitted, then this indicates that the message has 
been successfully transmitted. In this case, the current message is appended to outq, 
and the sequence number is complemented. 
(SP_ack_in) Pre^ ^Jq, e, b) = e = SP_ack_in:P 

Next sp_ack_infa' r > ® s (fo( |n Q) = Q(outq) v b * q(sn)) -* r = q) a 

((q(outq) < q(inq) A o = q(sn)) -> 
r - q[-»(Q(sn))/sn, 

(q(outq))»o(inq-outq)(0)/outq]). 
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With the validity condition for the send protocol module, we would like to capture 
the following: If the send protocol can rely on the fact that repeated transmissions of a 
packet eventually result in the repeated receipt of acknowledgements for that packet, 
then it guarantees that every message appearing in inq will eventually also appear also 
in outq. This requirement is stated in rely- /guarantee-condition form as follows: 

Valid SP s Rely* 5 * -* Guar SP 

Rely SP s DfVpePktsNXmitSPfp) - ODIvr^Msn))) 

Guar 89 s n(vs€Seq[Values])(s < Now(inq) -► 0(s < Now(outq))), 
where the formula Xmlt^) is the formalization of the statement: "packet p is 
transmitted repeatedly, without any transmissions of other packets," and the formula 
Dlv^o) is the formalization of "acknowledgements for sequence number b are 
received repeatedly, without receipt of any other acknowledgements." These formulas 
must be defined to be compatible (in a way that is made precise by Lemma II. 6 below) 
with the formulas Xmit TL (m) and Dlvr^m) in the transmission line specification. Thus, 

XmitSPtp) a DO(Occurs = SP_pkt_out:p) a 

D(Vp '€Pkts)(Occurs = SP_pkt_out:p ' -+p' = p) 

Dlvr^b) s DO(Occurs = SP_ack_in:b) a 

D(Vb '€Bool)(Occurs = SP_ack_in:o ' -♦ b ' = b). 

11.10.5 Specification of the Receive Protocol Module 

The receive protocol module interfaces between the SRTL and RSTL transmission 
lines, and implements the complementary half of the transmission protocol. It operates 
as follows: The state of the receive protocol module consists of two sequences, inq and 
oufq, of messages, and a boolean sequence number sn. The sequence inq records the 
history of valid messages (with duplications removed) that have been received from the 
unreliable.transmission line SRTL. The sequence outq records the history of messages 
that have been delivered to the receiver. Initially the sequence number sn in the receive 
protocol module's state matches the sequence number in the state of the send protocol 
module. The receiver waits for packets to be delivered by the SRTL transmission line. If 
a received packet has a sequence number that does not match the current sequence 
number, then it is ignored. If a received packet has a sequence number that matches 
the current sequence number, then the message is extracted from the packet and 
placed at the end of inq. In addition, the current sequence number is complemented. 
At any time, the receive protocol module can transmit acknowledgements for the 



191- 



complement of its current sequence number (i.e. for the sequence number of the last 
valid packet received). 

As in the previous specifications, let the finite set Values be given as a parameter. 
Define the interface of the receive protocol module as follows: 

Events RP = {\} + [RP_pkt_in: Pkts + RP_out: Values + RP_ack_out: Bool] 

ln RP = {A} + [RP_pkt_in: Pkts] 

Out RP = {X} + [RP_out: Values + RP_ack_out: Bool] 

Pkts = [msg: Values X sn: Bool]. 

Define the state set by: 

States RP = [inq: Seq[Values] X outq: SeqfValues] X sn: Bool]. 

In an initial state, both queues are empty, and the sequence number is false. 
lnit RP (q) s q(inq) = q(outq) a q(sn) = false 

The pairs that define the state transition relation Trans RP are given below. 

A RP_pkt_in event with packet p can occur at any time. If the sequence number in p 
does not match the current sequence number, then there is no effect on the state. If the 
sequence number in p does match the current sequence number, then the message 
contained in p is appended to inq, and the current sequence number is complemented. 
(RP_pkt_in) Pre RPjikUn {q, e, p) s e = RP_pkt_in:p 

(p(sn) = g(sn) -*■ r = q[-»q(sn)/sn, 

(q(inq))'p(msg)/inq]> 

A RP_ack_out event can occur only for the complement of the current sequence 

number. There is no effect on the state. 

(RP_ack_out) PreRp^^q, e) m e = RP_ack_out:(-»g(sn» 

Nex W_**_outfo' f > srs <> 

An RP_out event with message m can occur only if there is a message in inq that has not 
yet appeared in outq, and m is the first such message. The effect is to append m to 
outq. 

(RP.out) Pre RP ^(q, e, m) m e = RP_out:m a q(outq) < q(inq) a 

m = (q(inq-outq))(0) 
Next^g, r, m) s r = q[(q(outq))*m/outq] 
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The validity condition for the receive protocol module should capture the following 
two requirements: (1) If packet p is received repeately, then eventually 
acknowledgements, for the sequence number contained in that packet will be 
transmitted repeatedly; and (2) Every message that appears in inq will eventually appear 
in outq. Formally, 

Valid RP = Rely RP -* Guar RP 

Rely RP s true 

Guar RP s D(Vp€Pkts)(Dlvr RP (p) -♦ OXmit RP <p(sn») a 

D(Vs€Seq[Values])(s < Now(inq) -• 0(s < Now(outq))), 
where, as in the previous specifications, Dlvr RP (p) formalizes the statement, "Packet p is 
received repeately, without any receipt of other packets" and Xmit RP (to) formalizes the 
statement, "Acknowledgement o is transmitted repeately, without any transmission of 
other packets." These formulas are defined as follows: 
Dlvr RP (p) s DO(Occurs ■ RP_pkt_in:p) A 

D(Vp '€Pkts)(Occurs = RP_pktJn:p ' -*p' = p) 
Xmit RP (o) s DO(Occurs = RP_ack_out:o) a 

D(Vd '€Bool)(Occurs = RP_ack_out:o ' -» b ' ■ b) 

11.10.6 The Transmission Module Implementation Algebra 

In this section we define the transmission module implementation algebra A™'. 
Let the finite set Msgs of message values be given as a parameter. Define 

Pkts = [msg: Msgs X sn: Bool]. 
The index set for the interconnection is the set {SP, RP, SRTL, RSTL}, corresponding to 
the send protocol, receive protocol, send-protocol-to-receive-protocol transmission 
line, and receive-protocol-to-send-protocol transmission line component modules. 
Define the embedded algebras A abs , Agp, A Rp , A^^, and A RSTL as follows: 

A abs : Is the message transmission module event/state algebra A™, with the 

parameter set Values instantiated as the set Msgs. 
A^: is the send protocol module event/state algebra A SP , with parameter 

Values instantiated as the set Msgs. 
A RP : is the receive protocol module event/state algebra A RP , with 

parameter Values instantiated as the set Msgs. 



fu/siaic aiycuia /* 

parameter Values instantiated as the set Pkts. 



a srtl : ls tne transmission line module event/state algebra A TL , with 
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A OCT1 : is the transmission line module event/state algebra A TL , with 

parameter Values instantiated as the set Bool. 

Let the composite interface for the transmission module interconnection be 
defined as follows: 

Events™ 1 = {X) + [in: Msgs + out: Msgs + pkt.out: Pkts + pkt_in: Pkts + 
ack_out: Bool + ack_in: Bool] 

In™' = {X} + [in: Msgs] 

Out™ 1 = {X} + (Events™ 1 - In™') 
Intuitively, events in.m and out'.m represent, respectively, the receipt of message m from 
the sender and the delivery of message m to the receiver. Events pktjout.p and pktjn:p 
represent, respectively, the presentation of packet p by the send protocol module to the 
SRTL transmission line and the receipt of packet p by the receive protocol module from 
the SRTL transmission line. Events ackjouf.b and ackJn-Jj represent, respectively, the 
presentation of acknowledgement b by the receive protocol module to the RSTL 
transmission line and the receipt of acknowledgement b by the send protocol module 
from the RSTL transmission line. 

Define the abstraction map a™', and the decomposition map £ ™' as follows: 
o™'(e) = TM_in:m ife = in:m 

= TM_out:m If e » out:m 

= X otherwise. 



«™'(e) 


= SP_in:m 


if e — in:m 




= SP_pkt_out:p 


ife = pkt_out:p 




= SP_ack_in:b 


ife = ack_in:b 




= X 


otherwise. 


C(e) 


= RP_out:m 


ife = out:m 




= RP_pkt_in:p 


ife = pktjnp 




* RP_ack_out:b 


ife = ack_out:b 




= X 


otherwise. 


*™» 


= TL_in:p 


ife = pkt_out:p 




a TL_out:p 


if e = pkt_in:p 




= X 


otherwise. 
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5™. (e) = TL_in:b if e = ack_out:p 

= TL_out:b if o = ack_in:p 

= \ otherwise. 

11.10.7 Proof of Correctness 

In this section we prove the correctness of the implementation 
<5 a tm,, S abs , <S / > /e{SP , RP , RSTL , SRTL} >, where S^ is defined by <A ab8 , Valid™>, and S^ 
S RP , S RSTL , S SRTL are defined by <A^ Valid SP >, <A RP - Valid RP >, <A RSTL , Valid TL >, and 
^srtl' Valia " TL> > respectively. 

Invariance 

The correctness of the transmission module implementation depends only on the 
invariance of the following: 

0) <W in( rt m Gsp< irK >) A W ou ^) = <* RP (outq) 

(2) g SP (outq) < g RP (inq) < o SP (inq). 
Condition (1) is the abstraction relation Abs™^), and states that the abstract 
transmission module's inq is identical to the inq for the send protocol module, and that 
the abstract transmission module's outq is identical to the outq for the receive protocol 
module. Condition (2) is Lemma II.4 below, and says that the receive protocol module's 
inq is always an extension of the send protocol module's outq and a prefix of the send 
protocol module's inq. 

Condition (2) is not inductive as stated, and must be strengthened to permit an 
inductive proof of invariance. We therefore define the implementation invariant 
lnv TM, (g) by 

lnv TM, (q) = Rep TM, (g) a Abs™'(q), 
where Rep™'(g) is the representation invariant and Abs™'(g) is the abstraction relation. 
The abstraction relation is: 

Abs TM, (g) s q abs (inq) = g SP (inq) a q^outq) = q RP (outq). 

The representation invariant Rep™'(g) is defined as follows: 

Rep™'(q) ■ Queue(q) a (Start(q) v Send(g) v Flip(g) v Ack(g)), 

where 

Queue(q) s q^nq) > q^toutq) a g RP (inq) > g RP (outq) 
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and the formal definitions of Start, Send, Flip, and Ack will be given below. This 
invariant says that, at any instant of time, the histories inq and outq for the send and 
receive protocol modules satisfy certain prefix relationships captured by the predicate 
Queue. In addition, the transmission system is always in one of four kinds of states, 
corresponding to the four predicates Start(q), Send(g), Flip(g), and Ack(g). The 
situations covered by these four predicates, and how they evolve during execution, will 
now be described. 

In a state that satisfies Start, the send and receive protocol modules have the same 
sequence number, the send protocol module's outq and the receive protocol module's 
inq are identical, and no new packets or acknowledgements are currently in transit over 
the transmission lines. The predicate Start is satisfied by all initial states. 

States satisfying Start give rise to states satisfying Send when there is an 
unprocessed message at the send protocol module that has been output to (but 
possibly lost by) the transmission line RSTL. In a state that satisfies Send, the send and 
receive protocol modules have the same current sequence number, the outq of the send 
protocol module and the inq of the receive protocol module are identical, there is an 
unprocessed message at the send protocol module, there may be packets containing 
this message in transit over the transmission line SRTL, and there are no new 
acknowledgements in transit over RSTL. 

States satisfying Send give rise to states satisfying Flip when the first packet 
containing an unprocessed message arrives at the receive protocol module. In a state 
that satisfies Flip, the send and receive protocol modules have complementary current 
sequence numbers, the inq of the receive protocol module is equal to the outq of the 
send protocol module with the newly arrived message appended, and all packets in 
transit over SRTL or acknowledgements in transit over RSTL are old in the sense that 
they are for a sequence number that is not the one currently expected by the send 
protocol module. 

States satisfying Rip give rise to states satisfying Ack when the first 
acknowledgement for the newly arrived packet is transmitted over RSTL. In a state 
satisfying Ack, the send and receive protocol modules have complementary current 
sequence numbers, the inq of the receive protocol module is equal to the outq of the 
send protocol module with the still-unacknowledged message appended, all packets in 
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transit over SRTL are old, but there may be new acknowledgements in transit over 
RSTL. 

To complete the cycle, states satisfying Ack give rise to states satisfying Start 
when the first new acknowledgement is received by the send protocol module. 

For the formal statement of these predicates, it is convenient to define some 
auxiliary predicates, which describe possible states of the transmission lines SRTL and 
RSTL. 

The predicate SRTL_old is true of a state iff all packets in the SRTL transmission line are 
old, in the sense that they are for the opposite sequence number than the one currently 
expected by the receive protocol module. 

SRTL_old(q) m (Vn< |Q SRTL (inq-outq)|)(q SRTL (inq-outq)(n)(sn) * q Rp (sn)) 

Similarly, the predicate RSTL_old is true of a state iff all acknowledgements in the RSTL 
transmission line are old, in the sense that they are for the opposite sequence number 
than the one expected by the *»"d protocol module. 

RSTL_old(q) m (Vn < |q RST Jinq-outq)|)(q RSTL (inq-outq)(n)(sn) * q^sn)) 

The predicate SRTL_new is true of a state iff the SRTL transmission line queue consists 
of a {possibly empty) sequence of old packets, followed by a (possibly empty) sequence 
of new packets, each of which contains the first unprocessed message held by the send 
protocol module. 

SRTL_new(g) m (3m < ^^^(inq-outqJlKVn < Iq^Jinq-outq)!) 
((n < m — Q SRTL (inq-outq)(n)(sn) * q RP (sn)) A 
(n>m-+ Qgp^Onq-outqHn) - 

<msg: q SP (inq-outq)(0), sn: q RP (sn)>)) 

Similarly, the predicate RSTL_new is true of a state iff the RSTL transmission line queue 
currently consists of a (possibly empty) sequence of old acknowledgments, followed by 
a (possibly empty) sequence of new acknowledgements. 

RSTL_new(q) s (3m < |g RSTL (inq-outq)|)(Vn < |q RSTL (inq-outq)|) 
((n < m — q RSTL (inq-outq)(n) * q^sn)) a 
(n>m-+ q RSTL (inq-outq)(n) = q^sn))). 
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The formal definitions of the predicates Start, Send, Flip, and Ack are as follows: 
Start(q) = q SP (sn) = q RP (sn) a g SP (outq) = q RP (inq) a 

SRTL_old(q) a RSTL_old(q) 
Send(q) = q^sn) = q RP (sn) a q SP (outq) < q SP (inq) a q^outq) = q RP (inq) a 

SRTL_new(q) a RSTL_old(q) 
Flip(q) = q^sn) * q RP (sn) a q^outq) < q^inq) A 

(qgploutqHqspOnq-outqMO) = q RP (inq) A 

SRTL_old(q) A RSTL_old(q) 
Ack(q) s q SP (sn) * q RP (sn) A q SP (outq) < q^inq) A 

(q SP (outq))q SP (inq-outq)(0) = q RP (inq) A 

SRTL_old(q) A RSTL_new(q). 

We now consider the proof that lnv™'(q) is invariant. 

{Basis): N (Vq€States™')(lnit TM, (q) - lnv™'(q)). 

If q is an initial state then all queues are empty and the sn components of the state of 
both the send protocol module and the receive protocol module have value false. It is 
easily verified from this that Abs TM, (q) a Queue(q) a Start(q) holds. 

(Induction): N (Vq/eStates™ 1 , e€Events TMI )(Trans TM, (q, e, r) - (lnv™'(q) - lnv™'(r))). 
Suppose that lnv TM, (q) holds and that Trans™'(q, e, r) holds. 

We first examine the problem of showing that Abs™'(r) holds. Abs TM, (r) »s easily 
seen to be true, since the only events that affect components of the state upon which 
Abs™ 1 depends are the events in:m and ouf:m. Comparison of the definitions of 
Trans™, Trans SP , and Trans RP shows that the events in:m and out.m maintain the 
desired correspondence between the abstract module state and the states of the send 
and receive protocol modules. 

To see that Queue(r) holds, note that the definitions of Trans SP and Trans RP imply 
that the inq and outq components of the states of the send and receive protocol 
modules can only change in one of the following two ways: 

- A new message is appended to the end of inq. 

- The first element of inq - outq is appended to the end of oufq. 

Neither of these two kinds of changes can cause outq not to be a prefix of inq, and thus 
Queue(r) must hold. 
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To show that Start(r) v Send(r) v Flip(r) v Ack(r) holds, we claim that all events 
preserve the truth of the predicates Start, Send, Flip, and Ack, except in the following 
cases: 

- If Start(q) is true and e = pkt_out:p, then Send(r) is true. 

- If Send(q) is true and e = pktjn:p, with p(sn) = q RP (sn), then Flip(r) is true. 

- If Flip(q) is true and e = ack_out:b, then Ack(r) is true. 

- If Ack(g) is true and e = ackjmb, with b = Qgptsn), then Start(r) is true. 

It is a straightforward, but tedious process to verify the truth of this claim by exhaustive 
case analysis. 

The following consequence of the invariance of lnv™'(q) is the crucial fact used in 
the maximally and validity proofs below. 

Lemma II.4 ■ The following are invariant for the transmission module implementation: 

(a) Q SP (outq) £ q RP (inq) 

(b) q RP (inq) ^ Qsp(inq) 

Proof - The invariance of Start(q) v Send(q) v Flip(q) v Ack(q) implies the invariance of 
0) q RP (inq) = q^outq) v 

(Qsp(inq) > q SP (outq) a q RP (inq) = (q SP (outq))q SP (inq-outq)(0)). 
Suppose the first disjunct of (1) holds, that is qsp(outq) ■ q RP (inq). Then (a) is 
immediate. The invariance of Queue(q) implies that q SP {outq) < q^inq), thus yielding 
(b). Now suppose that the second disjunct of (1) holds. It is a fact about finite 
sequences that if s, s ' are finite sequences, and s > s', then $ > s'm, where m ■ 
(s - s')(0). This fact permits us to conclude, from the second disjunct of (1), that 
qsp(inq) > (qsptoutqJJq^inq-outqXO) = q RP (inq) > q^outq), yielding (a) and (b). I 

Maximally 

The maximality verification condition is: 

N (Vq€States™', e€Events™')(lnv TMI (q) a Enabled^, e) a Enabled RP (q, e) a 

Enabledg^q, e) a Enabled RSTL (q, e) 
-+ Enabted abs (q, e)). 
Examination of the definition of Trans™ shows that Enabled^q, e) is identically true 
unless e = ouf.m. Thus it suffices to show that, for all q € States™' and all m € Msgs, if 
lnv™'(q) and Enabled RP (q, out:m) hold, then Enabled^q, out:m) holds as well. 
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Suppose now that lnv TM, (q) and Enabled RP (q, out:m) hold. It suffices to show that 

(1) Qsp(inq) > q RP (outq) 

holds, for then the assumption that lnv™'(q) (and hence Abs™'(q)) holds implies that 
9abs(' nq ) > °a bs (outq) holds, which in turn implies that Enabled^q, out:m) holds. 

By definition of Enabled RP (q, outm), we know that 

(2) q Rp (outq) < q RP (inq) a q RP (inq-outq)(0) = m 

holds. Informally, if e = ouV.m, then m must be the first message in the receive protocol 
module's inq, that has not yet been transferred to its outq. The truth of (1) follows from 
(2) and Lemma 11.4(b). I 

Validity 

To prove that the validity verification condition holds for the transmission module 
implementation, we use Corollary 1.4. We use the well-founded partial ordering < on the 
set {SP, RP, RSTL, SRTL} that includes exactly the pairs SRTL < SP, RP < SP, and 
RSTL < SP. Under this ordering, hypotheses (1 ) and (2) of Corollary I.4 are as follows: 
(FMii) Comp"' 11 N (jGuar^gp a fiGuar Rr ]| RP a flGuar^JsRTL a IGuar 11 -]^ -* 

IGuar™!^ 
(TMI2) Comp™ 1 N JGuar TL l SRTL a JGuar RP J Rp a IGuar TL J RSTL - JRely^sp. 
These two conditions capture abstractly the important relationships between the validity 
conditions of the various modules. 

We now 'prove that (TMI1) and (TMI2) are consequences of the module 
specifications. 

Lemma 11.5 • Condition (TMI1) holds for the transmission module implementation. 

Proof • Assume Comp™' and IGuar^gp and JGuar RP J Rp . Using the definition of 
JGua^gp, we have 

D(Vs€Seq[Msgs])(s < NoWgp(inq) -► 0(s < NoWgp(outq))). 
From this and Lemma II. 4 (a), we obtain 

D(Vs€Seq[Msgs])(s < NoWgp(inq) -► 0(s < Now Rp (inq))). 
Using the assumption |Guar" P l Rp gives 

D(Vs€Seq[Msgs])(s < Now^inq) -► o(s < Now Rp (outq))). 
From an application of the invariance of Abs™', we conclude 
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D(Vs€Seq[Msgs])(s < Now flbs (inq) - 0(s < Now abs (outq))). I 

The proof of condition (TMI2) makes use of the following lemma, which expresses 
the principle that guided our choices for the definitions of the various Xmit and Dlvr 
formulas in the specifications above. 

Lemma 11.6 - The following hold for the transmission module implementation: 
N IXmit^Igp ~ IXmit^foMs^ 
N IDIvrS^lsp ~ IDIvr TL (b)l RSTL 
N IXmit R »l RP ~ IXmit TL (b)l RSTL 
N IDIvr RP (p)l RP ~ ffDIvr 11 ^)!^^. 

Proof - Straightforward from the module specifications and the definition of the 
decomposition map £ ™'. I 

Lemma 11.7 - Condition (TMI2) holds for the transmission module implementation. 

Proof - Suppose that Comp™ 1 , {[Valid""-)^, JValid^V, 2nd 5 V3!a7L lRSTL hc,d - 
Suppose, to obtain a contradiction, that -iffRely^gp holds. From the definition of 
!Rely SP j| S p, we know that 

(1) OppePktsXIXmit^lsp a D-"|[Dlvr sp (p{sn))l SP ) 

holds. That is, eventually a point is reached after which the packet p is transmitted 
infinitely often, without intervening transmission of other packets, but infinitely many 
acknowledgements for the sequence number contained in p are not received by the 
send protocol module. From (1) and Lemma II. 6 we infer 

(2) 0(3p€Pkts)<|[Xmit TL (p)]] SRTL A D-ilDlvr^CpfenHlgp). 
From (2) and the assumption that IValkf-lg^ holds, we deduce 

(3) 0(3p€Pkts)(|[Dlvr TL (p)l SRTL a □-'pvrSPWsnJJIsp). 

That is, packet p is delivered infinitely often to the receive protocol module, without 
intervening delivery of other packets, but infinitely many acknowledgements for the 
sequence number contained in p are not received by the send protocol module. From 
(3), another application of Lemma 11.6 shows 

(4) 0(3p€Pkts)(SDIvr RP (p)l RP A D->IDIvr SP (p(sn))l SP ). 
From this, an application of RValid RP ]| R p shows 

(5) 0(3p€Pkts)(IXmit RP {p(sn))l R p A D-"SDIvr SP (p(sn))l SP ). 

That is, an acknowledgement for the sequence number contained in packet p is 
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repeatedly transmitted by the receive protocol module, but infinitely many 
acknowledgements for p are not received by the send protocol module. Applying 
Lemma II.6, UValid TL ]] RSTL , and Lemma II.6 again, shows that 

(6) 0(3p€Pkts)(|Dlvr SP (p(sn))E Sp a n^HDIvr SP (p(sn))]] Sp ). 
This is a contradiction, and we conclude that (TMI2) must hold. I 
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Appendix III - Index of Definitions 



abstraction map 41 

9-abstraction map 113 

l/O-abstraction map 87 

abstraction operator 42 

asynchronous 97 

asynchronous product 84 

behavior 40 

9-behavior 113 

l/O-behavior 88 

primitive behavior 87 

canonical projection 55, 84 

coherent 57 

Completeness Theorem 1 20 

compatible coupling property 108 

composite machine 55 

composition operator 43 

computation 50 

valid computation 52 

consistent 

3-consistent 1 1 4 

l/O-consistent 88 

locally 3-consistent 116 

correct 44 

9-correct 114 

Correctness Theorem 58 

cycle 64 

decomposition map 41 

9-decomposition map 113 

canonical decomposition map 85 

l/O-decomposition map 107 

determinate 118 

quasi -determinate 1 1 9 

embedding 85 

enabled 86 

event 38 

input event . 84 

null event 38 

output event 84 

event/state algebra 137 

evolutionary 116 

explicit 86 
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fair 87 

future 115 

history 49 

history skeleton 51 

l/O-system 86 

implementation 44 

3-implementation 114 

implementation algebra 145 

implementation invariant 56 

Induction Principle 49 

inductive 49 

input-cooperative 86 

interconnection 41 

9-interconnection 114 

embedded interconnection 145 

interface 38 

abstract interface 41 

component interface 41 

composite interface 41 

9-interface 113 

l/O-interface 84 

system interface 85 

initial state set 48 

invariant 49 

isomorphic 107 

maximality condition 56 

machine 48 

embedded machine 137 

l/O-machine 86 

PS-machine 88 

system machine 86 

null step 48 

observation 40 

orthogonal 120 

possibilities mapping 59 

preserves 87 

strictly preserves 87 

productive step set 88 

reachable 49 

regular 117 

rely- /guarantee-conditions 60 

repeatedly 87 

runs 86 

satisfies 43 

skeletal sequence 50 
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spans 50, 51 

specification 43 

state-transition specification 52 

subset specification 47 

specification domain 113 

specification language 43 

state function 49 

state-transition relation 48 

translation 41 

Translation Lemma 147 

truncation 113 

truncation-closed 113 

validity condition 56 



